756998 - [i18n] Physical address display on contact preview (and input fields) should be localized: <zipcode> <city> vs. <city>, <zipcode> (e.g. DE,FR)

Status: RESOLVED DUPLICATE of bug 160601

(Thunderbird :: Address Book, defect)

Description

[David Bourguignon]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20100101 Firefox/12.0
Build ID: 20120420145725

Steps to reproduce:

I created a new address book entry, filling in the fields in the "private address" tab.


Actual results:

After clicking on "OK" the physical address info was displayed on the datasheet according to US-American format while my Thunderbird is localized for France. That means, this is what is currently displayed:

<street address>
<city>, <zipcode>


Expected results:

The physical address should have been localised to the French-European standard postal format:

<street address>
<zipcode> <city> (without a comma between the two)

Comment 1

[Hashem Masoud]

(In reply to David Bourguignon from comment #0)
What do you mean by the physical address?

Comment 2

[David Bourguignon]

Thanks Hashem for your feedback. What I meant by "physical address" is the postal address of a contact, ie. street and number, zipcode, city, and so on. Is that more explicit?

Comment 3

[Hashem Masoud]

(In reply to David Bourguignon from comment #2)
> Thanks Hashem for your feedback. What I meant by "physical address" is the
> postal address of a contact, ie. street and number, zipcode, city, and so
> on. Is that more explicit?

Yes, now it is clear. Sorry, I couldn't find you an answer, you can post your question here: https://getsatisfaction.com/mozilla_messaging and here: https://support.mozillamessaging.com/en-US/home

Comment 4

[David Bourguignon]

Thanks Hashem, but why do you forward me to Mozilla Support? It is clearly not an issue of Thunderbird misuse, but rather a i18n problem that wasn't consider at design time: the French/European version of Thunderbird is not correctly localized. Why isn't it possible to fix it within Bugzilla? :-) Thanks in advance!

Comment 5

[Thomas D. (:thomas8)]

Ludo, this applies not only to FR, but also to other countries like DE.
Are you sure that this is already exposed as a localizable string?
Do you know where that code/string lives?

If it's not exposed, we need this to be TB bug first before localization.

I also wonder if there many different ways of presenting addresses or if it's just two or three which could more easily be handled with pref (or pref and customized strings).

(In reply to David Bourguignon from comment #4)
> Thanks Hashem, but why do you forward me to Mozilla Support? 

Perhaps Hashem was hoping that we have a configuration option to tweak this and support could assist with finding out.

Unfortunately, I don't think it's configurable (not from the UI anyway), and yes, it should be configured correctly "out of the box" as explained in comment 0.

I would go even further and try re-arranging not only the contact's preview display, but also the input fields on the "Private" tab. These local habits are very strong, so *both* entering and viewing the zip code *after* the city is very odd for countries like Germany and France.

David, can you verify which (European) countries have zip code before city, and if there are any other frequent variants?

Comment 6

[Benoit]

I don't think we can do much l10n-side.

Thunderbird could add a localizable string for the preferred way to show addresses in a specific locale (e.g. if %1 is zipcode, %2 is city and the string say "%2, %1" for en-US and "%1 %2" for fr). It then becomes a l12y issue.

But then it would only work for local addresses. As soon as you have a contact in another country, addressing conventions change. 

For example, I live in Belgium where the house number is usually put after the street name while it is the opposite in France (fortunately, Thunderbird doesn't use separate fields for that). I guess there are other little details like this that could be different in Canada, Switzerland, Morocco, Algeria, Tunisia, ...

The only way to get this "right" in every case would be to maintain a database of local conventions and ship it with Thunderbird. I'm not sure it's worth the effort though. 
And it *still* wouldn't work for the input fields unless you force the user to choose a country first.

Comment 7

[Thomas D. (:thomas8)]

yea, I'm starting to see this is very complex to get right.
It has been discussed for 10 years in bug 160601 and due to the complexity, there is still no solution. And half solutions will probably break as much as they fix.

Comment 9

[David Bourguignon]

Dear Ludovic, Thomas and Benoit, thanks a lot for your quick feedback! I was guessing that if this issue wasn't addressed, it was because it is really a messy problem, with lots and lots of work for quite a tiny result. I fully agree.

In fact, I think being obsessively exhaustive is not the goal of free software projects with limited resources, Thunderbird included. They should rather focus on some innovative, smart, and not-so-difficult-to-implement sidestep solutions. Here is my proposal:

1) Forget about database-style contact info and focus on text blobs + search capabilities.

Observation #1: As many users, I guess, I very rarely use the private and professional address fields in the Thunderbird Address Book. Why? Because most of the time this info is provided by people in their email's signature, which is a plain text blob. Therefore, I simply copy and paste this blob in the "Additional Info - Notes" section of the contact card. This way, I don't have to worry with localization at all, because, of course, my contact has correctly formated its address! :-)

Proposal #1: Remove all database-like fields and aggregate the infos in a few large plain text fields. Allow full text search on these fields using a simple keyword-matching algorithm, useful to know for example which contacts live in a given city.

2) Consider that this problem is in fact linked to the old but mighty issue of the "business card" format.

Observation #2: The business/contact card info is lost on platforms and devices (mobile included) among many formats, syncing protocols, etc. Nearly nobody uses VCF as contact format in emails, but most people (including MS Outlook users) have either a text or HTML blob at the end of their messages as a "signature".

Proposal #2: Learn using a Bayesian engine or spot directly (using the common -- convention) the signature part of an email and automatically copy-paste the info into one of the "info blobs" of a contact card (see proposal #1) when the user click on "save the signature info".

What do you think? Of course, this is a major change in software design, but I think it would address two major issues at the same time and could be worth it... :-) Moreover, maybe I'm missing something, but I think these solutions would be closer to the current use of Thunderbird than anything else, therefore they should gather quick adoption.

Let's open another thread and close this bug if you think we are drifting away too much... :-) Thanks in advance for your feedback!