Feature request: Allow customization of the presentation order of fields of addresses
The order of elements in the ADR field of a vCard is fixed by RFC 6350, but the order of fields in a written postal address varies by locality. For example, many european countries (e.g. FR, DE) place the postal code before the city name (U.S. and vCard standard is to place the postal code after the state/province).
(See UPU standard S42 for the gory specifics).
Example:
123 High Street
San Francisco, CA 94114
USA
vs
27 RUE PASTEUR
14390 CABOURG
FRANCE
The RFC allows a properly presented postal address to be included in the ADR. LABEL:
ADR;LABEL="Mr. John Q. Public, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town, CA 91921-1234\n
U.S.A.":;;123 Main Street;Any Town;CA;91921-1234;U.S.A.
If the contact list and calendar don't need the individual ADR components, it would be preferable to let the user type in a freeform text label when entering a contact address, and do away with the individual components altogether.
For comparison: I think contact lists like Google Contacts parse user-provided address text in a sophisticated way to extract the components, but NextCloud may be able to just leave them blank. Roundcube lets the sysadmin configure an HTML template (e.g. for Europe, '{street}<br/>{locality} {zipcode}<br/>{country} {region}') into which fields get stuffed, and adjusts the order of the input fields to match the order of the fields in the template. Of course that approach is broken when the user wants to enter an address for a country that uses an address template different from that in the system template.
This issue affects data entry and presentation of contacts on the contact detail page, and also the autocompletion of nextcloud calendar event locations, and the presentation in IMip invite email. (There may be other places postal addresses are presented).
This was brought up and discussed previously in nextcloud/calendar#933.
Feature request: Allow customization of the presentation order of fields of addresses
The order of elements in the ADR field of a vCard is fixed by RFC 6350, but the order of fields in a written postal address varies by locality. For example, many european countries (e.g. FR, DE) place the postal code before the city name (U.S. and vCard standard is to place the postal code after the state/province).
(See UPU standard S42 for the gory specifics).
Example:
vs
The RFC allows a properly presented postal address to be included in the ADR. LABEL:
If the contact list and calendar don't need the individual ADR components, it would be preferable to let the user type in a freeform text label when entering a contact address, and do away with the individual components altogether.
For comparison: I think contact lists like Google Contacts parse user-provided address text in a sophisticated way to extract the components, but NextCloud may be able to just leave them blank. Roundcube lets the sysadmin configure an HTML template (e.g. for Europe,
'{street}<br/>{locality} {zipcode}<br/>{country} {region}') into which fields get stuffed, and adjusts the order of the input fields to match the order of the fields in the template. Of course that approach is broken when the user wants to enter an address for a country that uses an address template different from that in the system template.This issue affects data entry and presentation of contacts on the contact detail page, and also the autocompletion of nextcloud calendar event locations, and the presentation in IMip invite email. (There may be other places postal addresses are presented).
This was brought up and discussed previously in nextcloud/calendar#933.