Multi-language support

We sell our products about 35% outside the USA and that market is growing.

Multi-language support is a must for many reasons, like differences in formatting and calculation of time, date, weight, amount, currency, weight  etc. different character sets, misunderstandings due to buyer's limited English skills, etc.

< id="gwProxy" ="">< ="jsCall;" id="jsProxy" ="">

Greg Dinger wrote: FWIW, here is a store that is supporting Spanish:  www.ybravo.com

I tested that site, but it uses Google Translate (as a linguist and software localizer I do not recommend that at all for a serious business) and, when clicking on the language logo to switch the translation url also fails.
< id="gwProxy" ="">< ="jsCall;" id="jsProxy" ="">

Just to pipe in here, this google tool is only a temporary idea put in place by us.  We will develop a complete site in Spanish whereby when the Spanish flag is clicked the complete Spanish site will open up.  This site www.ybravo.com is only a few months old with much opportunity coming our way.  Years ago I was involved with a site from www.shopfactory.com which operates in multi-languages, but the cart itself at that time, had much work needed.

Just to give you ll a rough idea what a true internationalization and localization of PC would entail, here is a draft paper (so needs some fine tuning) I wrote on the subject for a marketplace site I used to sell on. It is not yet fully comprehensive but may help to spec out some day in the future most of the internationalization and localization work which needs to be done for PC:

----
1. Infrastructure
Get a Global Content Management System (like Trados or SDL), so you can have your translated content maintained worldwide. Those two software manufacturers are the standards worldwide, but smaller ones may be cheaper and still reasonably known, or translators may be able to load up and download from other software via special 'interchange' routines. Note that te core of this systems is what is called a 'translation memory' where all ccore text strings and their translations are stored. The TM allows you to leverage past translations, even if the translation is not an excat match. That saves a lot of money in 'translation costs'.

2. Dictionary
Before starting any localization, create a 'core translation memory', not to be confused with 'working translation memory'. This 'core translation memory' (CTM) should become your 'dictionary' where all unique words are being stored. They should be extracted from your present web site and stored together with the sentences they occur in, so context is established, since translations may differ a lot by context.Once this 'core translation memory' is set in stone, manage any changes to its content very carefully through 'version control' since any change here may have a big impact on your site wide localization. Next have this CTM translated (so not any sentences, just words) and have those translations reviewed by expert users in the different languages, to ensure they will approve that it fits the current 'lingo' as it is expected by web site users in a specific locale. Next add the content of this translated and approved CTM to your empty 'working translation memory' WTM and send that out for translation. Have the translated CTM again reviewed by expert users, possibly on a wider scale than with the WTM. Once the WTM is approved,  publish your localized sites with it and have translators maintain future content changes following this process.
Note: Consider prioritizing TM's for English speaking countries (which have at least 25% of variations in spelling of words (like localization vs localisation)!), so Canada, Australia, USA, UK), especially British since that language is the most commonly taught English in other European countries as well (sorry guys, NOT our US English).

3. Coding
Before you can publish a localized site, you need to have it internationalized. This means amongst others:
- Text display and processing
Code in the right character set when displaying or processing any text string (both incoming and outgoing), usually Unicode (allows 65,535 characters, some outgoing text may differ due to some browsers not liking Unicode), otherwise your characters will not display or will look awkward or a routine will fail altogether (Also, automated translation of dynamic text is necessary (like when a user enters a foreign address), since many characters cannot be read elsewhere, so this will cause problems like not being able to read a shipping address. This is already the case with Paypal badly internationalized payments emails which Paypal erroneously displays in foreign characters, so sellers cannot read them.). It also causes unnecessary filtering by spam filters set to delete such unreadable messages. Unicode will allow you to deal with double-byte languages like Chinese and Japanese.
- Navigation coding
Some languages impact your site navigation design. Example: With a vertical menu bar, you may put it in the left of your pages for English pages and in the right for Arabic pages because Arabic is a right-to-left language and people are used to start reading pages from right to left.
- Separate style and content
Use XML to store content only. That way translators do not have to deal with 'formatting issues'. It saves a ton of translation money that way. All translation tools (like Trados and SDL) work best using XML source files.
- Avoid embedding data and using CDATA
All data that is not text (e.g. Javascripts, SQL queries) should be kept outside of the document if possible and instead linked with an 'include' mechanism. Most translation tools (like SDL or Trados) do not handle CDATA well and it can be hard to keep track of inline CDATA code segments, which can be overlooked in the translation process.

- Use styles instead of embedded fonts on your css and use Unicode font faces
Otherwise embedded fonts make your viewer dependent on what font he has installed. .

- Formatting of numbers (decimal points, positioning of separators, character used as separator)
- Formatting of Telephone numbers, addresses and international postal coses/zip codes
- Text sorting order
- Date/time format, including use of different calendars
- Currency (symbols, positions of currency markers)
- Weights and measurements
- Paper sizes

4. Space
Create sufficient extra space on your site to deal with the different 'real estate requirements' per language. Example: German text on average uses 1/3 rd more characters per word. IT also uses more words per sentence.Bear in mind that amongst all languages, English is the most 'efficient' language. Any other language is less 'efficient'. With Asian languages you'll need more space because they are read vertically and the characters require a larger size than English characters to remain readable. Same with Hebrew.

5. To be determined

6. Graphics/images
Watch your costs and time to localize when designing graphics/images containing text. Keep that at a minimum. Those take long to localize (more manipulation costs and more tools needed). Replace text in a graphic/image with HTML Unicode text where possible.

7. Functionalities
This is a rough 'to do' list of 'international' functions that are advisable and are high priority to have for users selling and buying on your site:

7a. Internationalize registration
I already requested recently at ..............com a feature to register foreign users. Presently that does not really exist since foreign users cannot enter a country right now. My gut feeling is that such a feature ought to be priority #1, since one cannot trade properly without at least being registered properly. From the ‘registration’ will flow what other typical ‘local requirements’ one would have. One can even use a user's geo-IP to make a start with this, but further details are needed than just 'location', since languages may vary by location.

7b. Local date/time/calendar in localized date/time/calendar format
So user option to use 12 or 24 hour clock and different date time formatting depending on country and weekday order starting Monday or Sunday and also default display depending on locale. A listing should show both the local time/date/weekday of the seller and the local time/date/weekday of the buyer (viewer), plus the time difference and possible opening hours/weekdays in both locales, so each knows when he can communicate with the other.

7c. Local currency
Currency should be displayed as 'estimated amount' if listed in different core currency and as 'exact amount' together with 'estimated amount' in buyer’s currency. Also store and display what currency a seller will accept in payment, since this can vary. The currency sign may differ in placement (some are in FRONT of numbers and some are AFTER numbers. Make sure there is enough space for this.

7d. Local ‘amount’ formatting (this varies per country and sometimes per language)
Example: A separator can differ from a comma to a period and the location of the separator may differ. Make sure there is anough space for this.

7e. Local weights/measurements (like meters vs. yards or pounds vs. kilos)
These local weights/measurement symbols and local formats should be displayed at same time for both buyer and seller locales, so each understands what the other sees and can communicate about it (especially handy if using chat box). Distances and weights should have the highest priority to be displayed that way since they are already being used in listings, searches and booth details.

7f. Local language indicators
It would help users communicate with each other if each user would indicate in his profile what languages he feels comfortable with to trade with, either in writing or orally or both. This helps match up speakers of the same language and allows sellers to recognize immediately what language they are dealing with so they can try get a translation for what they want to say (even 25% of UK words are ‘strange’ to US sellers! :-) ). Additionally a ‘language’ indicator would allow ......com to offer customized automated translations of messages and screen in the future.
This feature is easy to implement but is quite an innovation as most sites do not have it for simple lack of understanding the seriousness of the communication challenges translated in loss of sales. It would lower the ‘communication barrier’ considerably and increase sales.
So, recapped, allow users to indicate languages, plus if it is written or oral and maybe even to what degree (like beginner, advanced, native).

7g. Local payment methods
As opposed to the USA where the banking system is very antiquated (so Paypal’s feebased P-to-P service had a lot of success solving that problem), most users in Europe are interested in using the already well developed (often feeless and instantaneous!) bank-to-bank-account transfer systems.
This will of course only become a point when non-US users trade amongst themselves.
Meanwhile I would recommend, for sales between US buyers and foreign buyers, to start offering Xoom.com as a service. They allow for a relatively modest flat fee bank-to-bank transfers (buyer pays) between a US bank account and a foreign bank account.
Also note that presently listed payment methods like ‘money order’ and ‘check’ will have to be ‘localized as well. A ‘US money order’ is not the same as a ‘foreign money order’. In the US domestic money orders do not incur fees, but foreign money orders do, unless they meet certain requirements like ‘issued to be cashed at correspondent US bank’, ‘in US$ only’, ‘sometimes international postal money order only, etc. Cashing these MOs without fees can also depend on what the policy is of a local US bank. Also, if a local check is listed as acceptable, it should not be visible for a foreign buyer, since foreign checks cannot usually not be cashed by a seller of another country.

7h. Local laws and taxes
It would be especially useful to provide users with information on local import and export rules as well as customs duties and sales taxes. Now each seller and buyer has to each time research this himself and they are usually never completely informed so make mistakes and have erroneous expectations which result in disappointments. I especially think all are interested in a priority of making the ‘taxes’ issued with imports more transparent so predictable.
Even if buyers often know they have to pay this, they would be much more comfortable with a site that simply discloses such information during the buying decision. It would prevent situations where buyer refuse shipments or negatively judge sellers and never buy with them again.

7i. Local geographic location
Various geographic location fields need to be ‘localized’, like fields for Country or Province vs. State vs. County, Postal Code vs. Zip Code (each has different formats). The country name will need to be changed according to a seller’s location/language, due to the outgoping postal service needing to be able to read it.

7j. Countries (and regions) blocked from buying and Countries with restricted payment methods, both per seller
We need geographic block and/restriction functionality. On the current main e-commerce sites it is impossible to specify countries that one does not want to sell to (often due to their bad postal systems or know card fraud). Sellers need to be able to create their own blocked list. Additionally it may be that one wants to accept purchases from certain countries (or regions) only if they pay by cash or postal money order, which ar both methods that cannot be revoked by buyers. In that case the buyer from each country should only see payment methods accepted for his specific country by seller. This will also allow foreign sellers to disallow checks from foreign countries (on Ebay this is currently impossible).
I would advice a hierarchical choice of regions as well as specific countries, so a seller can choose to spend more or less time on defining the blocks or limitations.
And finally the country/region list should be ‘internationalized’. Example: In all countries in the world except the USA, the concept of 7 geographic continents is accepted, but in the USA the concept of 6 continents is used. It would be wise to use the 7 continent concept for all users, in order to avoid miscommunication. Ebay developers did not understand this and left out New Zealand and Oceania altogether in the ‘continents’ grouping. Antarctica is not there either (I had a buyer there).
These type of ‘country block or restriction lists’ are common with credit card gateways and even on Paypal, but strangely have not been applied yet on sites like Ebay or Amazon.


< id="gwProxy" ="">< ="jsCall;" id="jsProxy" ="">

Edited by leeflang - 01-September-2009 at 2:26pm