#444 use profile.name_display on some pages

[vktimofeev]

... instead of the join of profile.name_given and profile.name_surname/

This is just a sketch code, however working good for me. It is a sort of "natural" solution to use the user defined format to display primary names instead of just concatenation of profile.name_given and profile.name_surname via a spacebar, as it is implemented in many places in the main branch now.

However such a solution is incomplete: for example, the names in the associations list are rendered from the serialized Person class instances

https://github.com/gramps-project/gramps-web/blob/31ed0bd98b8eec1b903f2215f91bcfaabcd7a97b/src/util.js#L45-L#53

and the Person class contains no name_display field which contained the primary name in the user defined format.

The serialized Person class instances are produced by the following backend code:

https://github.com/gramps-project/gramps-web-api/blob/fdb0d4b4157494994acc67572c8fc6312a12f06c/gramps_webapi/api/resources/util.py#L771-L774

...

https://github.com/gramps-project/gramps-web-api/blob/fdb0d4b4157494994acc67572c8fc6312a12f06c/gramps_webapi/api/resources/util.py#L809-L819

and the same code is used from src/components/GrampsjsSearchResultList.js

gramps-web/src/components/GrampsjsSearchResultList.js

Lines 96 to 101 in 31ed0bd

	${this.data.map((obj, i, arr) => {
	const desc = objectDescription(
	obj.object_type,
	obj.object,
	this.appState.i18n.strings
	)

via

gramps-web/src/util.js

Lines 311 to 314 in 31ed0bd

	export function objectDescription(type, obj, strings) {
	switch (type) {
	case 'person':
	return personDisplayName(obj)

.

Couldn't we add, for example the person profile to the serialized Person class instances when they are returned in the REST API reply? The serialized Person class instances on the client side can contain additional fields to the server side instances, can't they?

[DavidMStraub]

The people endpoint can include the person profile in the response for each person.

The challenge is when person objects are returned in the extended part of other primary objects, e.g. as participants of events. In that case, they don't have a profile key. There is a problem of exponentially increasing number of database calls here.

I think the first goal should be to use the name_display in all places where the names from the person profile are used at the moment.

As a second step, we can look at the remaining places, but this will require some deeper thoughts about modified API calls, performance etc.

By the way, another requirement is that the frontend should continue working with Gramps Web API 3.2.0, as the two components can be updated independently. So if name_display is not available, it should use name_given/name_surname/name_suffix instead.

[vktimofeev]

The challenge is when person objects are returned in the extended part of other primary objects, e.g. as participants of events. In that case, they don't have a profile key. There is a problem of exponentially increasing number of database calls here.

Yes, I see. In my initial comment I wanted just to mark some problems with our current approach to name formatting.

BTW, when we receive a serialized Person instance on the client, it may become convenient to use client-side implementation of the NameDisplay. However, in this case we would either have to send name formats from the database (a record in the metadata table) or limit the name formatting to applying the settings from the local storage of the browser (this code is not implemented yet, but I suppose it should be implemented within the current pull request). It may seem to be a good idea to use display_as field of the Name class instance which is a part of the Person class instance, but again, it requires the name format data from the database.

[DavidMStraub]

Thanks for the improvements, to me this looks good now, did you want to make additional changes in this PR?

[vktimofeev]

You are welcome!

I'm in the stage of research right now. I would skip name formatting code for charts for now - it has been modified recently, but I think it would be nice be able to set the name format for the charts via some form element etc...

Maybe I change the frontend code for timelines soon.

I also want to create the form for setting of name format on the user settings page, and this form would have as an effect in adding name_format argument to the query string - I believe this is relevant to this PR, but maybe it is better to create a new one.

And I have some reflections about exploiting /api/name-formats/ endpoint which exists probably since the first release of the Web API, but is not used by the frontend. Of course, this would require a separate PRs for the backend and frontend , but this is related to the name display formats topic. Please advise where could I start such a discussion?

[DavidMStraub]

Something I'm unhappy about is that this removes the underlining of the given name, which in my culture can be very helpful - usually it is the first one of the given name, but - especially historically - it can often be the second. (For instance, Johann Sebastian Bach's call name was actually "Sebastian".)

I think we can invert the order of the "underlining" code and the "name display or old version" code to keep the underlining also with the new format. The only problem is that it could underline something in the last name if it contains the call name string and we use a last name first format. Not sure we should worry about that.

[vktimofeev]

Yes, using the server-side rendered name_display hardly can be used to embed the HTML markup. Or, to be honest, can not be used at all.

Maybe if we adopt some code that would process the Name class instances on the browser side, such thing would be made configurable, but this is something about more complicated than a format string from gramps.gen.display.name

[DavidMStraub]

What I mean is we could define a function like (this is just ChatGPT, haven't tested):

function highlightCallName(givenName, callName) {
  const regex = new RegExp(`\\b(${callName})\\b`, "gi");
  return givenName.replace(regex, "<span>$1</span>");
}

and then we could do

return (
  nameDisplay
  ?  highlightCallName(nameDisplay, call)
  : `${highlightCallName(given, call)} ${surname} ${suffix}`
)

[DavidMStraub]

Sorry, using replace was a bad idea by ChatGPT, we cannot used it with Lit templates, that's why I had to use index and substring in my original implementation. Need to think about it more.

[sabal202]

Hi @vktimofeev, thanks for working on this — and to @DavidMStraub for the direction. I hit the same need (patronymic-ordered names render oddly in the web UI even though the desktop name-format is set), and independently arrived at the same approach you're taking here: prefer the server-formatted profile.name_display over the name_given + name_surname concatenation.

Since the implementations overlap, I wanted to share what I ended up with in case any of it is useful for this PR or a follow-up — happy to contribute it however you and David prefer, and to defer to this PR as the active one.

What I did at the helper level in src/util.js, so the behavior is consistent everywhere:

• personProfileDisplayName, personTitleFromProfile, personDisplayName prefer name_display when present, with the existing manual build as a fallback.
• An empty name_display ("") falls through to the manual build rather than rendering blank.
• personDisplayName only uses name_display in given-first mode, so surname-first callers keep the manual build (since name_display encodes a single configured order).

Beyond the components in this PR, I also routed these through the helpers, since they had the same hand-built concatenation:
objectRender.js, GrampsjsChildren, GrampsjsConnectedParents, GrampsjsChromosomeBrowser, GrampsjsMapSearchbox, GrampsjsViewTimeline.

I also added unit tests for the helper fallback chain (prefers name_display, falls back on empty/missing, surname-first untouched) in test/unit/util.test.js.

I ran into the same limitation you and David noted: person objects embedded in the extended part of other objects don't carry a profile, so name_display isn't available there without backend changes — those spots still fall back to the manual build.

If it helps, I'm glad to open a small follow-up PR with the extra components + tests once this lands, or push them to your branch — whatever keeps things tidy on your end. Thanks again!

---

For reference, here's my branch as a single, DCO-signed commit (frontend unit tests pass, eslint/prettier clean) — happy for any of it to be cherry-picked or ignored:
sabal202/gramps-web@9bd3530...feat/server-name-display

[DavidMStraub]

Thanks for this update!

I think in any case we need to start a new PR, as this one has too many conflicts.

I ran into the same limitation you and David noted: person objects embedded in the extended part of other objects don't carry a profile, so name_display isn't available there without backend changes — those spots still fall back to the manual build.

I've been relying on those non-profile person objects more and more recently (timeline etc.), so what I'm wondering at this point is whether we should actually port Gramps's name display module to Typescript and just do all of iit in the frontend...

[vktimofeev]

Hi @DavidMStraub and @sabal202 ,

I've already ported the Gramps's gramps.gen.display.name class to TS less than an year ago. Not the entire corresponding Gramps's code, of course, but all that is necessary to fetch the name format data from the backend, which can be stored as a default for entire system or for each Name instance separately and format it the same way as the GUI version do. Unfortunately, I had to abandon my work on this project, I hope only temporarily. I think I'll come back to it soon enough. It seems that I haven't pushed this JS code to my fork of gramps-web project here on the Github.com, but I'm sure it is not lost. If this code is of slightest interest for anybody, I can push it until the end of this week and then to adopt it to the current versions of the Gramps Web.

Cheers,

Vitaly