Woocommerce-services: Non-roman characters are printed as question marks (?) on labels

Created on 14 Jun 2019  Â·  9Comments  Â·  Source: Automattic/woocommerce-services

Non-roman characters are not accepted by the extension, when creating labels.

To test this, I entered the following set in the Name field: Test 서울특 Testing.

This was printed as Test ??? Testing on the actual label after it was purchased. See below:


Image Link: https://cld.wthms.co/3OUGRj

[Pri] Low [Type] Enhancement [Type] Good First Change

Most helpful comment

Indeed, it can be a scenario, especially for international orders. Although the items are delivered to the address and not the person so postal carriers don't usually need a person's name. However, they are needed in some scenarios (for example, proof of ID) or for the recipients (for example to distribute in an office).

I suggest that we email [email protected] and ask them. We can't be the first to encounter this issue. They can guide us to a solution.

All 9 comments

I tested this when working on #1862 and I think it's not a problem we can fix because it's a limitation of the way USPS generates the labels. Their software just cannot render most unicode characters.
See https://www.easypost.com/blog/2013-05-20-foreign-language-support
I tested Piña colada and it was correctly converted to Pina colada so it wouldn't have '?'s but there no converting the asian characters so I think there's nothing we can do.

@aleftick, any thoughts on this one?

Are foreign characters in the destination address an important use case? Maybe we need some input validation when they're entering a destination address to warn them if the characters they're entering cannot be displayed on the label?

Indeed, it can be a scenario, especially for international orders. Although the items are delivered to the address and not the person so postal carriers don't usually need a person's name. However, they are needed in some scenarios (for example, proof of ID) or for the recipients (for example to distribute in an office).

I suggest that we email [email protected] and ask them. We can't be the first to encounter this issue. They can guide us to a solution.

We have another report of this in 2992714-zen.

In this case, the character is °. This symbol is ascii code 248, so possibly there is a workaround here?

The degree character is used in many addresses in Spain, and this is affecting the merchant's ability to ship to a number of addresses.

I suggest that we email [email protected] and ask them.

@aleftick did we reach out to easypost at all? Is that something you'd like Happiness to do?

I just sent EasyPost an email.

@aleftick Has there been any update on this?

EasyPost responded. In short, the carriers don't support those characters and EasyPost will replace them with "?".

We support encoding with UTF-8, which allows 2 million+ characters. Unfortunately, most carriers cannot handle all the characters in UTF-8, and these unsupported characters show up as '?' on the carrier's labels. This is a problem with each carrier and not something we can fix on our end. When printing labels, all carriers support ASCII which has 128 characters (characters 'a' through 'z' and numeric values 0 through 9). The terms "ASCII" and "ISO-8859-1" (sometimes "ISO-8859 Part 1") tend to refer to one of the more limited character sets that are commonly accepted by all carriers.

The address validation would signal the issue with a non-roman character issue in the address. It wouldn't for the addressee but that doesn't impact deliverability.

@c-shultz - At some point, we could have better error messaging to inform users to switch the non-roman characters to roman characters.

Hello, do you know if easypost support auto-translation (transliteration) from non-roman to latin alphabet as it was mentioned in their blog?

Was this page helpful?
0 / 5 - 0 ratings