Addresses with accented characters return a not found address page in the Get Map feature



MailNews: Address Book & Contacts
16 years ago
7 years ago


(Reporter: msanz, Assigned: rchen)



Windows NT

Firefox Tracking Flags

(Not tracked)


(Whiteboard: needinfo)



16 years ago
If an address in the AB contains upper-ascii (I imagine CJK will be worse, but I
haven't tried) in the street or city or country, the address is not mapped. For
example: (Spanish address)

José Pérez
Araucaria 24
28039 Madrid

Will map correctly in a Spanish map

José Pérez
Ávila 14
28039 Madrid

Won´t map the street, but will show a city map

José Pérez
Araucaria 24
28039 Madrid

Will return:
Error Code: 400 mqs.searchReq did not return out array

José Pérez
Mayor 2

The map is centered in Spain, the city is not shown.

So, if the country is not in ascii, not even the city gets mapped. If the street
contains upper ascii, city is returned. And if city is in upper ascii, country
is returned. Bad luck for "España" , for example.

Nominating, seems like a stopper to me

Marina, Xianglan, can you try with CJK?


16 years ago
Keywords: nsbeta1

Comment 1

16 years ago
same with cyrillic address, if the country is not in ascii it won't be found.
With the country in ascii but the city in cyrillic only the country get mapped.

Comment 2

16 years ago
Montse, i don't think it's a stopper and here is why: I tested it a little bit
more and i believe now that it is a legitimate operation to type a country name
in ascii into the "country" field. To input non-ascii chars into all fields
requires the back-end ( which is Mapquest) to be fully i18n'ed. But there is a
limitation on their site, unfortunately they have only three intl web sites :
french, german and uk. On the french site the accented chars are accepted. I
don't know how we can redirect the map and internally link it to those three
existing sites (provide another button for worldwide maps?). My understanding is
that AB is internally unicode, so could it sniff the charset i input and map me
to the right country? But what do we do with chars that are common to several
languages like cyrillic or chinese? Finding those chars will confuse the search
as of what country to map to(China or Japan)? etc.. 
Seth, could you please clarify the specs, the limitations of the implemenation
and the future plans? Thanks. 

Comment 3

16 years ago
Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020204
on Win NT SP6 (US version)

Comment 4

16 years ago
I do think it's a stopper, we need at least to investigate what's going on here
and maybe MapQuest can implement some fix or a better user experience.

Comment 5

16 years ago
For Japanese and Chinese address, if I put Japanese/Chinese country name, it
gives me a USA map. And if I put English country and city names (Japan, China),
it does give me Japan and China map with the city in the center.
I think we can do something in localized builds. For example, for French build,
we can have Mapquest France for the mapping function. But since Mapquest only
have those three international sites, is it possible to get the local map
services for other localized builds?


16 years ago
Keywords: intl

Comment 6

16 years ago
adding Kevin Murray because we need a decision on it for localized builds

Comment 7

16 years ago
Do we think this is client code or MapQuest? If it is client code, and is a
trivial fix, I would say we should plus this. If it is heavily involved work, I
would say that based on where we are on timing, that we should hide the button
in Int'l builds until we get some more QA on the feature (I'm worried that we
have more bugs that simply don't know about). If you're confident that this is
the only bug, then by all means we should fix it, providing of course that it is
more important than the other I18N and l10N bugs on the current plus list.  

Comment 8

16 years ago
Seth, is it easier to try to fix this or to just hide the button in
international builds?

Comment 9

16 years ago
Discussed in 2/28/02 Mail & News bug meeting.  We need to know if pref changed
to point to international site, does this work?  Also does MapQuest work with
non-ASCII characters?
Whiteboard: needinfo
I'll investigate.   this should be a matter of properly escaping the address.
Assignee: racham → sspitzer

Comment 11

16 years ago
from the Mapquest intl sites the accented chars are excepted meaning it works
for French, German, Italian,Spanish, Danish,Dutch, Norwegian,Swedish. I don't
see double-byte languages there. It looks like the design is to make the
acceptance for accented chars work only fron the intl sites of Mapquest. I don't
know how we can deal with it: provide a link, redirect, hide it on North
American side?  
I take back my comment, I don't think it is a matter of escaping.

some other ideas:

1)  for certain localized builds (fr, uk, and de) point to other sites, like 
for german builds, point to (or .fr or

2)  for those other localized builds, set the pref to another service

3)  for those other localized builds, set the pref to "" to hide the button.

seems like this could be both a release note and a note in the localization 

FYI, here's how the pref works:

// the format for "mail.addr_book.mapit_url.format" is:
// @A1 == address, part 1
// @A2 == address, part 2
// @CI == city
// @ST == state
// @ZI == zip code
// @CO == country
// if the format is "", no mapit buttons will appear in the addressbook
pref("mail.addr_book.mapit_url.format", "

I don't think this is stop bug.

Comment 13

16 years ago
Added l10n folks on the cc list.

Comment 14

16 years ago
The MapIt button works with English name "Tokyo Japan", but not any Japanese 
names. So, for JA version, we need to disable the MapIt button in file 

Interesting, the "" is another company's website, a totally 
different thing! Also, noticed that Yahoo USA uses MapQuest for their map 
service, but did not.

Comment 15

16 years ago
reassigning to rchen who I think is handling localization bugs.  We'll need to
change the pref in localized builds if you decide to + it.
Assignee: sspitzer → rchen

Comment 16

16 years ago
 Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.8+) Gecko/20020301 Netscape6/6.2.1+

I entered this info into my AB:
   [2-10] Rue Tonduti-de-l'escarène

Clicking on the Get Map button seems to correctly generatse this URL:

Note that it encodes the non-ASCII as %-encoded UTF-8.

We should try the same test with the

Comment 17

16 years ago
Since I was asked by the MachV team to assist with bug triage, I hope no one
will think I am intruding on this bug.  The bug was marked critical, but others
do not feel it's a stopper.  Can the team come to consensus on this bug?

Comment 18

16 years ago
ok, it seems like people suggest that we change the pref to "" in localize
build. If so, we need to make the pref reading localizable. 
nsbeta1- minus this one and try to plus the new bug 132203 which make the pref
Keywords: nsbeta1 → nsbeta1-

Comment 19

16 years ago
This doesn't sound like anything to do with "accented characters" to me.  It
sounds like the site only accepts place names in English.  And not very many
English words happen to have accented characters.  I bet it behaves the same
when entering an unknown word even without accented characters.
(But unable to test sorry)

Comment 20

16 years ago
Changing QA contact from nbaca to marina.
QA Contact: nbaca → marina

Comment 21

16 years ago
*** Bug 146727 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey

Comment 22

11 years ago
=> invalid per comment 19
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.