Home / Our Blog

Archive for March, 2009

Web 2.0 Development and Multilingual Support

Monday, March 23rd, 2009 by Gene Averbuch

We have been talking a lot about web 2.0 development and enterprise 2.0 solutions in our blogs but I don’t think anyone has touched on the subject of multi-lingual support.  I believe that anyone with a commercial web site would ultimately decide for having the web site support several languages, given that they have the budget and time to implement the multi-lingual support.  So I think the question is not necessarily “should the site have multi-lingual support” but “how should multi-lingual support be implemented”.

Let’s start out with the way it shouldn’t be done and why:
Many site owners decide to copy the entire site and change all of the images/menus/text by hand.  The main reason why this is a bad idea, is because you essentially end up doubling the amount of administrative work involved in the maintenance of the site.  Each time a new page gets added, it now needs to be added twice.  Each time a new product is available in the store, it needs to be added twice.  If you are taking online orders, that’s two systems that you have to reconcile as opposed to just one.  There are other issues such as it taking more time to release new functionality, apply bug fixes, and so on.  I’m sure there are other ways of doing it wrong, but this seems to be the most prevalent one.

The right way of doing it is by having one site that lets the administrator edit text in all supported languages. This applies to products, menu names, regular text, etc.  The administrator simply selects the language they want to write in, selects what they want to translate, types the text in the text editor and that’s about it.  The system has a centralized database that stores all content on all languages.  When someone clicks on the “Spanish” version, for example, it just displays the content that has been marked as Spanish.  In other words, it’s still just one copy of the site but depending on a user’s selection, it displays the appropriate language.  The main benefit of this system is that it allows the administrator of the site to change any block of text at any time in any language or even add new languages without having to copy the website.  As an extra step, if the various languages are targeting different audiences in different countries, the domain type of the site can be configured to automatically display a particular language.  In other words, www.intechnic.es can be made to automatically display everything in Spanish.  This is actually the way both of the Intechnic sites are set up.

Web 2.0 Development - Shipping Automation

Wednesday, March 18th, 2009 by Ilya Bernshteyn

Why Web 2.0 and Shipping Automation? Well people generally think of Web 2.0 Development as clean, modern design style, which is true, but it’s also about functionality that makes sites not only easier to use, but also easier to operate by automating tasks. So obviously if you’re shipping products yourself, say for example you have an e-commerce site, and all or some products are shipped by you instead of by a third party, you eventually need to package the products and print a label, no breaking news there. You could do it the old-fashioned way, which is charge the customer for shipping, knowing it’ll usually cover the cost of the carrier’s price, then go on the carrier’s site and print a shipping label. But this could become time-consuming once volume picks up, plus all of the carrier’s shipping prices fluctuate so if you’re not comparing shipping costs you could be overpaying in some cases.

What if there could be an automated shipping process? All of the shipping carrier’s realized that they needed to open up their systems so that websites can get real-time shipping information, which is why there is a UPS™ API, DHL™ API, USPS™ API, and a FedEx™ API. By the way, don’t let people tell you that there’s no way someone got the USPS API to work because “their technology isn’t as developed”, it’s not true, yes it’s more difficult, but after some back and forth with USPS, we got it to do what we wanted. Now back to automation, let’s say you have margins to charge for shipping, no more need to setup separate shipping types, a system integrated with all the Shipping APIs can let customers choose a shipping type (1 day, 3 days, 7 days, etc.) and then it’ll automatically check all the carriers and get the lowest priced label, then apply any margins you’ve setup (for example – increase shipping price by 10%). Then you get the order info and a ready to go shipping label. Just an example though, perhaps you have a special account with a carrier? Then you can use your account number and choose a setup with just one carrier. Lots of room for creativity in Web 2.0 Shipping Automation Development!