Posted by TR on February 23, 2011 at 12:22am
3 followers
| Project: | Ubercart |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
In order for Drupal translation to work on country names / zones, these must all be stored in the database in English with a Latin character set. While the country names have been changed to English for Drupal 7 / Ubercart 3, some zone name are still entered in other character sets. Here is a list of the CIFs which need to have their zone names Romanized:
china_156_1.cif
egypt_818_1.cif
greece_300_1.cif
japan_392_1.cif
kazakhstan_398_1.cif
taiwan_158_1.cif
thailand_764_2.cif
russia_643_1.cif
ukraine_804_1.cif
Comments
#1
I am wondering if this is actually required. We don't translate other parts of addresses, so why translate zones? Shouldn't they just be stored as their native name?
I can see adding translations could actually cause problems here - if you use this data for address labels, you want the country name in your local language (so your domestic shipper knows to send it overseas), but the zone name in the language of the destination country (so it gets delivered correctly after arriving in the country).
#2
The reason to Romanize them is if we want to use Drupal translation. If we don't need translation, then I guess it doesn't need to be done. Or it can be done like whoever wrote the Taiwan cif did; enter the zones twice - once in latin characters and once in local script.
I suspect the Universal Postal Union (http://www.upu.int/) has a standard on what should be done with zones, and I suspect that standard says English is the lingua franca for addressing mail. I haven't tried to look this up yet.
Personally, I have shipped thousands of orders internationally, to 67 different countries, including all the above countries except Egypt and Kazakhstan. Never once has a customer typed any part of their name or address in a local script (although I allow it); I have always addressed the packages using the latin character set, and the packages have always arrived. In fact, it's interesting that most customers confine themselves to ASCII and don't even use the extended latin character set.
#3
TR, where is this .cif located?I misread, I was looking for the Thailand cif not the Taiwan. See below posts.
#4
To elaborate, I'm using PayTrace as the payment gateway. Orders to countries (like Thailand) where the zone is non-ASCII are being rejected by PayTrace.
#5
I translated the Thailand cif, it is attached.
The remaining countries that I see needing translation are:
#6
I'm going to throw these up here now, though they are to be considered a work in progress. As TR pointed out in IRC they will need _update() functions to translate sites' databases that are using the existing names into the new English names. That will be a fun job. For now, here they are with the correct zone names, but only Ukraine, Russia, and Japan have the correct codes - others are using the alpha codes that are apparently very old and do not coincide with the ISO codes.
For documentation's sake, here's where I've been getting data from: http://en.wikipedia.org/wiki/ISO_3166-2:GR
The abbreviation can be changed to get the appropriate country quickly, i.e. Japan = JP = http://en.wikipedia.org/wiki/ISO_3166-2:JP
Edit: let me add that these are for D6 and will need to be updated for D7 as well.