Multi-language support
Printed From: ProductCart E-Commerce Solutions
Category: ProductCart
Forum Name: Suggestions
Forum Description: ProductCart Suggestions
URL: https://forum.productcart.com/forum_posts.asp?TID=2992
Printed Date: 22-November-2024 at 8:15pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com
Topic: Multi-language support
Posted By: Sangano
Subject: Multi-language support
Date Posted: 01-September-2009 at 1:03pm
|
Oh woe is me... The dilemma is that I need multi-language support, but I love ProductCart.
EI: I know this subject has been brought up in the past, but how hard would it be for EI to implement multi-language support in PC? I ask this because (1) it would be a great thing to have to address multiple markets, and (2) there are projects that I have in the pipeline that require multi-language support. As it stands now, it looks like I'll have to use something other than PC for these projects. Can someone at EI tell me if there is anything in the works that may enable multi-language support in the future? I know it won't be in time for my current requirements, but to have the option in the future would be fantastic.
I came upon an example in CRE Loaded's demo page that shows the control panel options on the product configuration pages of their system. It's interesting (though I don't like CRE in general). There are tabs for setting the description, options etc. in various languages.
http://demos.creloaded.com/creloaded_pro/admin/login.php?email_address=demos@creloaded.com&password=demos - http://demos.creloaded.com/creloaded_pro/admin/login.php?email_address=demos@creloaded.com&password=demos
At any rate, some feedback from the EI staff on this issue would be greatly appreciated. Again, I'd love to know that this is something you're working on addressing. (Fingers crossed.)
Best regards - Alan
|
Replies:
Posted By: katharina
Date Posted: 01-September-2009 at 1:23pm
|
Let me add my "German" mustard to this. I'm not in desperate need of it, plus my store is in the USA so the main language should be English. Yet, I'm an importer of German gift items and serve the German-American community. In that regard it would make all sense to have it. I would love to see this option, and I will use it if available. So my support for this feature is here, but I can continue without it too. ------------- Katharina ******************* www.GermanPlaza.com ******************* |
Posted By: leeflang
Date Posted: 01-September-2009 at 1:33pm
|
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" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Posted By: Greg Dinger
Date Posted: 01-September-2009 at 1:40pm
Posted By: leeflang
Date Posted: 01-September-2009 at 1:57pm
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" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Greg Dinger wrote:Posted By: Greg Dinger
Date Posted: 01-September-2009 at 2:02pm
Posted By: ybravo12
Date Posted: 01-September-2009 at 2:13pm
| 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 http://www.ybravo.com - www.ybravo.com is only a few months old with much opportunity coming our way. Years ago I was involved with a site from http://www.shopfactory.com - www.shopfactory.com which operates in multi-languages, but the cart itself at that time, had much work needed. |
Posted By: Sangano
Date Posted: 01-September-2009 at 2:13pm
| Thanks, Greg... But yeah, it's a bit clumsy, that one. I did come across this site http://www.novaflex.com/ - http://www.novaflex.com/ customized by Port City Web. http://www.portcityweb.com/ - - www.portcityweb.com |
Posted By: leeflang
Date Posted: 01-September-2009 at 2:16pm
|
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/ 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" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Posted By: leeflang
Date Posted: 01-September-2009 at 2:21pm
|
Regarding the novaflex.com site by portcity, nice try, but not advisable. Look at http://www.novaflex.com/productcart/pc/viewPrd.asp?idcategory=429&idproduct=1882 - this product page which is supposed to be in French! PS And it is also not a true store/shopping cart < id="gwProxy" ="">< ="jsCall;" id="jsProxy" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Posted By: Sangano
Date Posted: 01-September-2009 at 2:24pm
|
Seems fine to me. This is the url your link sent me to... http://www.novaflex.com/productcart/pc/viewPrd.asp?idcategory=429&idproduct=1882 - http://www.novaflex.com/productcart/pc/viewPrd.asp?idcategory=429&idproduct=1882
Everything is in French on my end.
- Alan
|
Posted By: leeflang
Date Posted: 01-September-2009 at 2:27pm
|
Nothing French about: Part Number: Features and Benefits < id="gwProxy" ="">< ="jsCall;" id="jsProxy" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Posted By: leeflang
Date Posted: 01-September-2009 at 2:37pm
|
Interesting. I use Firefox as browser and clicked on the FR icon to swap to French. The first display of the swapped language page shows a mix of English and French. the second time I try swapping with FR, it shows full French. When I copy the url of the French page into a freshly opened browser it shows the mix again. Not well internationalized. It requires a lot of understanding how to internationalize the code for input and output in a browser, before one can get a proper translated display. Same input does not equal same output. < id="gwProxy" ="">< ="jsCall;" id="jsProxy" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |
Posted By: Sangano
Date Posted: 01-September-2009 at 2:47pm
|
@leeflang
I see what your saying now. But for me it only seems to mix languages when clicking from an external link. I've been trying to switch languages on various products in FF & IE but have been unable to reproduce it except for sometimes when I click your link.
No, it's not perfect, but it seems to be the best I've seen yet on a PC powered store.
- Alan
|
Posted By: leeflang
Date Posted: 01-September-2009 at 3:01pm
|
Anyway, Alan. It does not compare to the complexity of a true shopping cart internationalization/localization. This is just a collection of 'translated pages' without a cart. Peter< id="gwProxy" ="">< ="jsCall;" id="jsProxy" =""> ------------- Peter http://208.112.123.87/LeeFlang/Default.aspx (site under development) |