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?
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?
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?
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. ***
=> invalid per comment 19
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.