X-PHONETIC: Consistency with Stock, Google, Apple etc.: Add Option to View &Edit Additional Name Fields

[DiagonalArg]

Checklist

• I made sure that there are no existing issues - open or closed - to which I could contribute my information.
• I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
• I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one feature request.
• I have read and understood the contribution guidelines.
• I optionally donated to support the Fossify mission.

Feature description

The stock Android contacts app has various extensions for phonetic names. In Stock, you'll see that the Name field has a drop-down (up arrow ^) that offers more fields, and then a "More Fields" link that provides even more, including:

"phonetic last/middle/first name",

Export from Stock:

FN:Prefix First Middle Last, Suffix
N:Last;First;Middle;Prefix;Suffix
X-PHONETIC-FIRST-NAME:PFirst
X-PHONETIC-MIDDLE-NAME:PMiddle
X-PHONETIC-LAST-NAME:PLast

Export from Google Contacts is the same:

FN:Prefix First Middle Last Suffix
N:Last;First;Middle;Prefix;Suffix
X-PHONETIC-FIRST-NAME:PFirst
X-PHONETIC-MIDDLE-NAME:PMiddle
X-PHONETIC-LAST-NAME:PLast

So the request is to add the X-PHONETIC properties as editable.

Why do you want this feature?

Consistency with the Stock contacts app, with Google and Apple CSV.

Additional information

Note that this request relates to:

Support Import of Apple & Google's vCard v.3.0 Extension, itemN.X-ABLabel. Fossify Supports these as "Custom"

and

Read and Interpret Properly Stock Android's "Nickname" field.

and

Support department field

and

Add option to edit structured addresses.

[Aga-C]

Most of these are already supported by the app (check Manage shown contact fields). Please check the app once again, and limit your feature request only to these fields that aren't already supported or there's no feature request for them (e.g. Department is already requested here: #168).

[DiagonalArg]

@Aga-C / Done. Thank you for pointing this out, and I'll also make a comment regarding the "Department" field on #168 .

[Aga-C]

How is the nickname different from the one already existing in the app?

[DiagonalArg]

How is the nickname different from the one already existing in the app?

It isn't. If you read the edited OP, you'll see that NICKNAME is represented differently in the Stock Android App, so when importing/ reading a vcard, the idiosyncratic representation would have to be translated.

[Aga-C]

If it isn't a new field, but it's only about importing/exporting, then please create a separate feature request. Let's keep this feature request only about missing fields, so in this case, it should be only about phonetic names.

[DiagonalArg]

@Aga-C / Thanks for sticking with it! I've split off the second issue, here:

#194

[Aga-C]

Another question: what is X-FILE-AS and how it should be editable?

[DiagonalArg]

@Aga-C /

X-FILE-AS: is a Google extension field in which you can put any text. I think it's meant to be some kind of a tag, and is distinct from CATEGORIES:.

I wonder if it would help for me to just fill all fields in Google, Nextcloud, and Stock Android, export as v-Card, and and post all those for comparison?

[Aga-C]

X-FILE-AS: is a Google extension field in which you can put any text. I think it's meant to be some kind of a tag, and is distinct from CATEGORIES:.

If so, it's already reported: #32. Please write about it there and keep only X-PHONETIC in this issue.

I wonder if it would help for me to just fill all fields in Google, Nextcloud, and Stock Android, export as v-Card, and and post all those for comparison?

See: #85.

[DiagonalArg]

@Aga-C / Labels in Stock appear to be something different. When I create a label in stock, and add a contact to it, then exporting that vcard, I don't see any added fields in the vCard itself.

As for #85 , my point would be to create contacts on each of the platforms and then export those various vCards in order to compare/ contrast. Right now, there is just a plethora of differences between the various representations. If we just had all the data together, AI could just write a translation mechanism between them.

[Aga-C]

@Aga-C / Labels in Stock appear to be something different. When I create a label in stock, and add a contact to it, then exporting that vcard, I don't see any added fields in the vCard itself.

But if Google exports labels to this field, then I don't see a reason to keep it as something separate just because stock app doesn't do it this way. We can't create separate use cases just because each app works differently. If X-FILE-AS keeps a tag/label in Google Contacts, then we can use it for #32. Another thing is, IMHO, that we shouldn't care so much about all X-* fields. They aren't standard, and I don't see any reason to put much effort to support something that Google does, but some other app doesn't.

X-PHONETIC is different here, as many apps store phonetic names in this field as you've mentioned, so it's a kind of informal standard. To summarize - let's keep this issue only about X-PHONETIC.

As for #85 , my point would be to create contacts on each of the platforms and then export those various vCards in order to compare/ contrast. Right now, there is just a plethora of differences between the various representations. If we just had all the data together, AI could just write a translation mechanism between them.

#85 would be the best place to write down such comparison. No need to create another issue for this.

[DiagonalArg]

@Aga-C / Check regarding #85 . Will do.

I wasn't clear what X-FILE-AS is, but looking closer, I see that it's part of the name field. (See image, below.) It's the name under which the contact should be filed, as opposed to the name of the person, nickname, or organization. What do you think should be done with this? Should I break it out?

**

**

[Aga-C]

Thanks for explanation. If so, isn't it the same as #129?

[DiagonalArg]

@Aga-C / This (below) is the most general vCard I could generate from Nextcloud. While FN: is generated from a form with a single field in Nextcloud, and that field can be anything (here "First Middle Last"), N: is generated from a form with multiple fields: Last, First, Additional, Prefix & Suffix. As far as I can tell, other providers usually generate FN: (for first name sort) automatically from N: (for last name sort), ie. for Stock Android, Google, Apple.

I've only found "File As" (X-FILE-AS) in contacts.google.com, which seems to have been introduced to solve the sorting problem by creating some kind of hierarchy. Roughly, if "File As":, then file (sort) using that. If N: and FN:, then sort using N: when ordering by last name, FN: when ordering by first. If none of those are present, but ORG: is, then file under that (maybe secondary sort using TITLE). That seems to be approximately what's going on.

So there is some overlap and conflict here regarding X-FILE-AS and Nextcoud's breaking the FN: / N: link. For general compatibility, maybe the issues could be handled this way?

Sorting imported cards (compatible with present behavior):

If X-FILE-AS is present, assume that's the sort field.
Otherwise:
a. sort by FN: (first name - which is the default now where "Start Name by Surname" is off),
b. sort by N: (last name) if "Start Name with Surname" on.

Creating:

One option is to keep compatibility with what seem to be the default standard except Nextcloud (?), by keeping N: and FN: linked. In that case, "File As" (X-FILE-AS) could be one of the hidden fields (expose-able by "Manage shown contact fields") that could be filled in or not.

Another option is to go with NextCloud and separate N: from FN:, by default sorting on FN:. In that case, while "Start Name by Surname" would work as it has historically, turning that off (the default) would not be "Start(ing) Name by" First Name. Rather it would be sorting via whatever is in the FN: field.

If you're interested in my advice, I'd suggest keeping it as is, and add "File-As". The issue with Nextcloud might be solved by:

1. Preferably getting Nextcloud, the seeming outlier, to recognize X-FILE-AS. (They are also in heavy development.)
2. Or, a "Nextcloud" switch on export from Fossify, which would copy any present "File-As" into FN:

BEGIN:VCARD
VERSION:3.0
PRODID:-//Sabre//Sabre VObject 4.5.4//EN
UID:2f7079e3-c9e8-48ef-9452-fda56300677f
FN:First Middle Last
ADR;TYPE=HOME:;Suite 666;555 Foo St.;Bar City;Baz;77777;Bumble
EMAIL;TYPE=HOME:foo@bar.com
TEL;TYPE=HOME,VOICE:555-1212
CATEGORIES:Auto
TITLE:Title
ORG:Company
BDAY;VALUE=DATE:19000101
URL;VALUE=URI:http://example.com
X-SOCIALPROFILE;TYPE=TWITTER:twitterexample
X-MANAGERSNAME:
ITEM1.X-ABDATE;VALUE=DATE-AND-OR-TIME:19200101
ITEM1.X-ABLABEL:_$!<Anniversary>!$_
NEXTCLOUD1.X-ABLABEL:FederatedCloud
X-ANNIVERSARY;VALUE=DATE:19200101
DEATHDATE;VALUE=DATE:19800101
N:Last;First;Additional;Prefix;Suffix
NEXTCLOUD1.CLOUD;TYPE=OTHER:foo@matsodon.social
GENDER:O
IMPP;TYPE=SIGNAL:foo32
GEO;VALUE=URI:geo:90.000\,0.000
NICKNAME:Nickname
X-PHONETIC-FIRST-NAME:PFirst
X-PHONETIC-LAST-NAME:PLast
RELATED;TYPE=RELATIVE:Cousin Last
RELATIONSHIP:FRIEND
LANG:ebu-ke
TZ:Africa/Bissau
REV;VALUE=DATE-AND-OR-TIME:20241129T153519Z
END:VCARD

[Aga-C]

We won't create a separate field just because Google works differently. Let's keep to standards. Everything what you've written here about File As belongs to #129, as it's still about keeping the display name. 

Also, as I said before, let's keep this feature request ONLY about X-PHONETIC.

[DiagonalArg]

@Aga-C / Fine, though Nextcloud works different too. (I also use it.) There's the rub. In that case, I might not suggest going with either one.

I can edit here and copy my comment over if you'd like.

[DiagonalArg]

@Aga-C / Alright, edited above, and reworked comment, here, where I'm in agreement with @RokeJulianLockhart on keeping FN: / N: linked.