Bugzilla

(In reply to Alessandro Castellani [:aleca] from comment #6)

> > Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

I think we're misunderstanding each other here.
Thunderbird 91 has two separate address line inputs for each address, and they are not independently labelled, but just share the label "Address". Let's call them
- Address Line 1
- Address Line 2

So whatever localized structure users have used, but they surely had a first line and a second line as appropriate for their purposes.
When migrating to 102, we're swapping these two lines (even in Magnus current patch which merges them afasics). WHY?
I don't think we should reverse the order of data as we find it in TB 91. This is far from being a marginal issue. For large datasets, this can cause loads of manual work of getting the two lines back into the correct (localized) order!

> Alongside that, reversing the order only visually would create inconsistency between the stored and viewed data.

This bug is about *keeping* the TB 91 order of address lines, not reversing it.

> The 91 UI was wrong and done arbitrarily without any consistency, and we can't assume users always wrote street address and extended address in the same order (in Italy the apartment goes after the street address, but in Canada is the opposite).

Sorry, but that's missing the point. TB 91 UI had a first and a second address line.
We can safely assume that users have filled those in the correct order *according to their localized order principles*.
We should just maintain that order instead of reversing it, especially if we decide to merge the data.

> **Possible solution**
> - Merge those fields into the regular street address and never use/expose pobox and extended address fields.

Merging *may* be OK (although it's still arguably dataloss), but we must merge in the right order.

> - Don't do anything and let the user change the data if they need it and don't like the order. 
> IMHO, this is a very minor and marginal issue that doesn't create any real problem other than an initial "uh, the address is reversed".

I disagree, see above.

(In reply to Alessandro Castellani [:aleca] from comment #6)

> > Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

I think we're misunderstanding each other here.
Thunderbird 91 has two separate address line inputs for each address, and they are not independently labelled, but just share the label "Address". Let's call them
- Address Line 1
- Address Line 2

So whatever localized structure users have used, but they surely had a first line and a second line as appropriate for their purposes.
When migrating to 102, we're swapping these two lines (even in Magnus current patch which merges them afasics). WHY?
I don't think we should reverse the order of data as we find it in TB 91. This is far from being a marginal issue, especially if we merge. For large datasets, this can cause loads of manual work of getting the two lines back into the correct (localized) order!

> Alongside that, reversing the order only visually would create inconsistency between the stored and viewed data.

This bug is about *keeping* the TB 91 order of address lines, not reversing it.

> The 91 UI was wrong and done arbitrarily without any consistency, and we can't assume users always wrote street address and extended address in the same order (in Italy the apartment goes after the street address, but in Canada is the opposite).

Sorry, but that's missing the point. TB 91 UI had a first and a second address line.
We can safely assume that users have filled those in the correct order *according to their localized order principles*.
We should just maintain that order instead of reversing it, especially if we decide to merge the data.

> **Possible solution**
> - Merge those fields into the regular street address and never use/expose pobox and extended address fields.

Merging *may* be OK (although it's still arguably dataloss), but we must merge in the right order.

> - Don't do anything and let the user change the data if they need it and don't like the order. 
> IMHO, this is a very minor and marginal issue that doesn't create any real problem other than an initial "uh, the address is reversed".

I disagree, see above.

(In reply to Alessandro Castellani [:aleca] from comment #6)

> > Alex, would reversing the field order to preserve Street Address before Extended Address (as in TB 91 UI) be an easy gain here (both for display and edit mode)?

I think we're misunderstanding each other here.
Thunderbird 91 has two separate address line inputs for each address, and they are not independently labelled, but just share the label "Address". Let's call them
- Address Line 1
- Address Line 2

So whatever localized structure users have used, but they surely had a first line and a second line as appropriate for their purposes.
When migrating to 102, we're swapping these two lines (even in Magnus current patch which merges them afasics). WHY?
I don't think we should reverse the order of data as we find it in TB 91. This is far from being a marginal issue, especially if we merge. For large datasets, this can cause loads of manual work of getting the two lines back into the correct (localized) order!

> Alongside that, reversing the order only visually would create inconsistency between the stored and viewed data.

This bug is about *keeping* the TB 91 order of address lines, not reversing it.

> The 91 UI was wrong and done arbitrarily without any consistency, and we can't assume users always wrote street address and extended address in the same order (in Italy the apartment goes after the street address, but in Canada is the opposite).

Sorry, but imo that's missing the point. TB 91 UI had a first and a second address line.
We can safely assume that users have filled those in the correct order *according to their localized order principles*.
We should just maintain that order instead of reversing it, especially if we decide to merge the data.

> **Possible solution**
> - Merge those fields into the regular street address and never use/expose pobox and extended address fields.

Merging *may* be OK (although it's still arguably dataloss), but we must merge in the right order.

> - Don't do anything and let the user change the data if they need it and don't like the order. 
> IMHO, this is a very minor and marginal issue that doesn't create any real problem other than an initial "uh, the address is reversed".

I disagree, see above.