Description: Some countries (including the UK and Ireland) require 'locality' as part of a postal address. This denotes the town/village area seperate from the postal town or city. (https://en.wikipedia.org/wiki/Post_town#Locality) There is no field for this in Options > User Data Not having this makes creation of and use of templates with fields less efficient in countries that require such in a postal address. Adding this would not hinder those who do not need it. Steps to Reproduce: 1.Tools 2.Options 3.User Data Actual Results: Tools > Options > User Data No field for locality/village/town exists. Expected Results: Would like an extra field to make address data more flexible/useful in countries that use longer address formats. Reproducible: Always User Profile Reset: Yes Additional Info: I think other countries that would benefit include, Thailand and Japan, likely many more too.
Seems reasonable to me. And we do already adjust to use different field in Options -> User Data between en_US and en_GB not sure how that is achieved. But looks like Unicode CLDR has deprecated/dropped postal code records, not sure where we'd get the data if we make it more locale aware. perhaps implement external: https://github.com/google/libaddressinput
ODF defines sender-street, sender-city, sender-postal-code, etc. but no extra attribute for the locality. Consequently we have no variable that could deal with something like senderextra-locality. Besides the ODF limitation, this wall of input fields is not welcoming (would personally expect just a long multi-line string for the whole address; with the odds of not being able to split the content).
Created attachment 200495 [details] Shows UK post office address guide compared to Libreoffice fileds
(In reply to Heiko Tietze from comment #2) > ODF defines sender-street, sender-city, sender-postal-code, etc. but no > extra attribute for the locality. Consequently we have no variable that > could deal with something like senderextra-locality. > > Besides the ODF limitation, this wall of input fields is not welcoming > (would personally expect just a long multi-line string for the whole > address; with the odds of not being able to split the content). Maybe, but then there are two uses within the UI. The actual ODF 1.3 §7.3.6 [1] defines these Text: fields as "Subsequent author fields capture information about second and following authors for a document." Along with those of the §7.3.7 Author name and initials, those details are captured in UI Tools -> Options -> User Data and per document to its File -> Properties. Yet, it seems we don't restrict their use to the exact ODF schema, e.g. bug 105841 or bug 113511 for populating the name fields. See UserProfile.xcs [2] for the content written into ODF. The second would be for the data schema populating the Address Block for the Mail Merge wizard [3]. IIANM we actually don't store/treat such data as ODF §7.3.6 Text. Rather the wizard Address element values are taken from table columns and use text:database-display, text:table-name, text:table-type, text:column-name structure to populate address from the database table space. The wizard currently provides these address elements (localized IIANM): Title (None) First Name Last Name Company Name Address Line 1 Address Line 2 City State Zip Country Telephone private Telephone business Email Address Gender Can be seen that the Wizard could be adjusted to provide an additional field for 'locality' to use in postal addresses where it could be helpful, with no impact or dependence on ODF as they are table content. =-ref-= [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1415276_253892949 [2] https://opengrok.libreoffice.org/xref/core/officecfg/registry/schema/org/openoffice/UserProfile.xcs [3] https://opengrok.libreoffice.org/xref/core/sw/inc/dbui.hrc
... > > The wizard currently provides these address elements (localized IIANM): > Title > (None) > First Name > Last Name > Company Name > Address Line 1 > Address Line 2 > City > State > Zip > Country >... So 'Address Line 1' is 'street' in the user info and Field > Sender But Address Line 2 does not appear in either. Adding Address line 2 to user data -would solve, with field as 'locality'?
(In reply to aa from comment #5) > > So 'Address Line 1' is 'street' in the user info and Field > Sender > > But Address Line 2 does not appear in either. > > Adding Address line 2 to user data -would solve, with field as 'locality'? No, they are available within the Mail Merge wizard to customize the address block. And, the MM follow different paths from User profile in source. In MM they are describing the Table content (Column feilds, and Row data records) to be used in the MailList. While the .xcs notes what is recorded for Author/Subsequent author and is available currently to include in document meta. While ODF §7.3.6 text:sender-street and text:sender-city and text:sender-state-or-province aren't used in the mail list. The text:sender-postal-code could be reused and assigned to the locality to extend the .xcs. The .xcs for user profile has gotten a few changes for signature or domain membership, but has been generally unchanged for about 20 years when there was some localization for ru_RU users (see OOo era i69133). Seems like both the Mail Merge and the User name/address could be tweaked.