Closed Bug 126326 Opened 23 years ago Closed 17 years ago

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

Categories

(SeaMonkey :: MailNews: Address Book & Contacts, defect)

Product:
SeaMonkey
Component:
MailNews: Address Book & Contacts
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: msanz, Assigned: rchen)

References

Details

(Keywords: intl, Whiteboard: needinfo) 

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
Spain 

Will map correctly in a Spanish map

José Pérez
Ávila 14
28039 Madrid
Spain

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

José Pérez
Araucaria 24
28039 Madrid
España

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

José Pérez
Mayor 2
Cáceres
Spain

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?
Keywords: nsbeta1
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.
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. 
Using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020204
Netscape6/6.2.1+
on Win NT SP6 (US version)
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.
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?
Keywords: intl
adding Kevin Murray because we need a decision on it for localized builds
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.  
Seth, is it easier to try to fix this or to just hide the button in
international builds?
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
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 http://www.mapquest.de/ (or .fr or .co.uk)

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 
kits.

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", "http://www.mapquest.com/maps/map.adp?
country=@CO&address=@A1%20@A2&city=@CI&state=@ST&zipcode=@ZI");

I don't think this is stop bug.

Added l10n folks on the cc list.
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 
"mailnews.js".

Interesting, the "mapquest.co.jp" is another company's website, a totally 
different thing! Also, noticed that Yahoo USA uses MapQuest for their map 
service, but Yahoo.co.jp did not.
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
Running:
 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
   Nice
   AL
   06000
   France

Clicking on the Get Map button seems to correctly generatse this URL:
http://www.mapquest.com/maps/map.adp?country=France&address=%5B2-10%5D%20Rue%20Tonduti-de-l%27escar%C3%A8ne%20&city=Nice&state=AL&zipcode=06000

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

We should try the same test with the www.mapquest.fr.
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?
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
localizable.
Keywords: nsbeta1 → nsbeta1-
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)
Changing QA contact from nbaca to marina.
QA Contact: nbaca → marina
*** Bug 146727 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
=> invalid per comment 19
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.