iData Technologies Blog

Content is currency

Posted 5/7/2011 7:36:54 PM by Mark Reichard

We've quoted Mike Berkley's blog post previously in which he said that "content is currency --- companies can print their own, but most don't."  The truth of that statement really struck me today as I was looking at the Google Analytics reports for our site --- especially because of the traffic that one fairly random blog post has been getting.  Several months ago, I posted a simple html/css solution to an issue that I had in working on a customer site.  I thought it was a good solution, and I wanted to share it.  I had no intention of trying to attract search engine traffic, and I certainly didn't optimize the post to attract traffic.

Last month, that post got over 1700 pageviews, all from organic search results on sites like Google, Bing and Yahoo.  Because I took a couple of minutes to write a quick post several months ago, our site is still getting thousands of pageviews a month from folks who otherwise might not have come.  That has real value for us, even if HTML and CSS tips are not really what we are all about. 

But, you may ask, is it really like being able to print your own money?  I think so, but there are some caveats.  Just like being able to print you own money would require a high quality printer and special inks,  having people with valuable knowledge in a position to share it requires an investment in the right tools.  At least as important, though, is the developing the skill and habit of producing content.  Creating good Web content takes practice, and you have to know something worth sharing.  Also, not every blog post will attract traffic, which is why making creating content a habit and an integral part of the culture of an organization is so important --- you never know which posts will attract traffic, so at the end of the day it is a numbers game.

Tags: Content ManagementComments

Options for Multilingual Web Development

Posted 5/7/2011 2:51:54 PM by Mark Reichard

Converting your Website to provide content in more than one language can be relatively simple, or it can be large project that represents a major investment for your organization.  The nature of the project depends on several factors:

What you want to accomplish by adding additional languages.  If are just entering a new market and want a Web presence to introduce yourself, your options and priorities are different than if you need to launch a fully functional e-commerce site to serve a large and demanding customer base.

The technology your current Website is built on.  If your site is based on a content management tool (like WordPress™ , Joomla™, or SiteCore™), your process and options will be different than if your site is static HTML or uses internally developed programming to display content. Internally developed solutions often assume date and number formats, currency symbols and screen text that are not appropriate for international audiences, while the menus and links in static HTML sites are not built to display multiple languages.

How frequently the site is updated and how many target languages you have.  For relatively static sites to be translated to one additional language, a different approach is appropriate than for frequently updated sites in several languages.  It is critical to plan for updates, since a Web site must be maintained and updated in order to be valuable.

Whether you plan to customize site content such as images, colors and icons to be culturally appropriate for each target language and locale.

The availability of Web designers and technical resources with multilingual Web site experience and language skills.  Some approaches to translating your site rely on substantial help from Web designers or IT folks and rely on them to correctly place translated text.

What are the options?

Depending on what you hope to achieve from your translation project, there are usually several options for translating your site ranging from relatively low-cost, entry-level strategies to more robust, fully globalized approaches.  In general though, at each level there are better and worse choices.  The table below summarizes some of these options:

Project Scope

Not Recommended

A Better Approach

Limited.  Appropriate for small, relatively static HTML sites, or larger sites where you need to:

  • Introduce yourself to a new market
  • Provide a limited service for a small but important customer segment
  • Test the waters.

Minimizing translation vendor costs by:

  • Manually cutting and pasting content into Word® documents and using internal resources to manually place translated content in target files.  This error prone and has a high TCO. 
  • Requesting a single, low flat rate on translations.  This misses the large and increasing benefit of Translation Memory.

Minimize translation costs by selecting key content to translate --- don’t request a translation quote for your entire site, including news releases from 10 years ago and information about last year’s trade show.

Leverage technology.  Allow translation vendors to help with file preparation to avoid cut and paste.

Consider a content management solution.

Consider a micro-site in the target language with only key content.

Moderate.  Appropriate for larger sites where:

Functionality such as e-commerce or data-driven applications must be multilingual.

Most site content needs to be translated due to customer demand or legal requirements.

Content changes regularly and multiple authors must create content.

Roll-your-own content management solutions, including things like separate database columns per language, “if/then” logic around languages, etc.  These are difficult and expensive to maintain.

Work with experienced professionals to internationalize your site or application.

Implement best of breed technologies and strategies, such as content management, resource strings and translation memory.

Work with your vendor to implement a system for workflow management of translation requests.

Large.  Appropriate for sites where:

  • Large quantities of content must be translated.
  • Multiple authors are involved.
  • E-commerce or other dynamic functionality is required.
  • Customization of content by locale/language is required.

Creating separate sites per locale -- due to the duplication of effort and lack of central control.

Cut and paste document preparation.

Roll-your-own content management.

A multilingual Web Content Management solution such as iData’s Synapse Publisher™ CMS or SDL Tridion®.

Consider a Global Translation Management system for shared Translation Memory and workflow automation

Tags: Content Management, TranslationComments

Resources for Section 508 Compliance and Accessibility

Posted 2/14/2011 7:59:35 AM by Mark Reichard

I wanted to share two quick resources for testing your pages for accessibility and compliance with Section 508 of the US Federal Rehabilitation Act.  If you are unfamiliar with Section 508, it mandates that the Web sites of US Federal Government Agencies remove barriers in their electronic communications that would prevent disabled people from accessing those communications.  More information is available here, and the US Government's Section 508 Web site is available here.

One question you may have is whether Section 508 applies to you if you don't develop sites for the US Government.  There are several reasons that building accessible sites is good practice.  First, it is the right thing to do.  Thought of another way, when you build accessible sites, you are choosing not to build barriers that exclude people based on their differences.  We recognize that excluding people based on their differences is wrong in employment, building design, availability of services and many other fields.  Web accessibility is just a logical extension of that recognition.

Section 508 is also being understood to apply to more than just Federal Agency Web sites.  Many city and county governments are specifying that their Web sites must be 508 compliant, and even agencies that receive federal funds are doing so.  Getting into the habit of building accessible sites is a good idea for Web developers because they may have to do so on any government funded project.

Finally, sites that work well with screen reader technology tend to also be quite readable to other devices outside the normal desktop computer world, specifically Internet search engine spiders and mobile devices.  This means that by building an accessible site, you are not only doing the right thing, you will also likely benefit from better search engine results and your site will work better with mobile devices.

So, the tools that I wanted to recommend are:

AChecker: an online accessibility checker funded by the government of Ontario.  The tool is available here and information about it is here.

Cynthia Says:  a on online tool offered through a collaboration between the International Center for Disability Resources on the Internet and HiSoftware.  The tool is available here.

One note about these tools.  As we've been going through our site and checking for 508 compliance, we've found that the two tools frequently disagree.  Cynthia Says allows for some workarounds that AChecker does not.  This seems to be because Cynthia Says is targeted specifically at 508 compliance, so keep that in mind when you review the results.  Also, one caution --- you may find that you need to be careful with content from external sources.  One area where we still have work to do is our blog, specifically where we include markup from SlideShare.   Be aware that sometimes you will need to tweak content that you get from an external service.

Tags: Content ManagementComments