Improve support for 2 last names (like in Spain) adding a "Second Last Name" field

+17 votes


Currently if we follow the Spanish Naming Conventions there are several glitches on the site behavior:

  • the link in the last name points to a page that has no sense, because the combination of the 2 last names is unique to each person, it is not shared by ascendants or descendants
  • the site automatically and incorrectly fills the double last name when you add new ascendants or descendants while only the first last name is passed

So my proposal is to add a new field to the site called "Second Last Name" which will be filled only by Spanish people (or other countries if applicable).

What do you think?


in WikiTree Tech by Óscar Frías G2G1 (1.2k points)
edited by Óscar Frías

Hi Keith,

This is the "Ancestry México" search page:

(Click on "BUSCAR", top right corner)

There are 3 Name fields:

  • Nombres = Given name(s)
  • Apellido paterno = Paternal Last Name
  • Apellido materno = Maternal Last Name


Outstanding.  Thank you.  Very slick.
I would love to see the separate second name field.
This is something that should be added - it is impossible to correctly name a Spanish born person on Wikitree.  You have to alter the LNAB to make it fit the site.
In this conversation is an actual solution. Have a look, ask questions.
Sadly, a bit too complicated for most folks who are dropping in to add Grandma.

Really, it's so simple. You are not doing the programing. What is complicated about completing a predesigned form like you do for profiles at the moment. That is just another smaller form for the name fields.
I can appreciate that it is simple for you but in looking at the page you posted, I didn't make it too far down.  In reading your comment above, you could be speaking in Japanese and it would make as much sense to me.

I'm thinking that for the vast amount of Wikitreers, if it isn't point and click, its too complicated.
Are you suggesting that this fix is already in place and we can implement or is this a hypothetical solution?
Mr SJ Baty. If you are unable to understand my previous reply or the contents of the link I provided, I am unable to help you.

3 Answers

+6 votes
Best answer


I'm new to Wikitree and I dived straight in to adding my tree and discovered much to my horror that in adding 100+ profiles in what I intuitively though would be the best way is completely at odds with the recommended "style" for Spanish Last names.

I "assumed" that the Last Name At Birth (LNAB) would be the paternal (principal) surname and the Other Last Name  (OLN) would be used for the maternal surname and proceeded accordingly.

I soon noted that the names displayed with a weird aka before the maternal surname and I assumed this was down to some wikitree rule governing the OLN field that I would need to fix later.

Upon research in the G2G to understand better the naming conventions for Spanish surnames should be I did find a guide for Spanish Naming Conventions in Wikitree which is most detached from reality thing I've ever encountered. Evidently the best solution arrived at is to put both surnames in the LNAB field on the grounds that the both names are really one name.  This is incorrect and highly misleading.  It is not intuitive and no database best practise would be to put two pieces of different data in the same field.  The paternal surname and maternal surname are separate pieces of information and are unique to the individual person profile. They are not repeatable in the parents or children of any given person about would only repeat in the siblings of the person. Other comments point out it really screws up the search and match functions as I'll illustrate:

My Great Grandfather, Ramon Granados Marquez

He would in the recommended naming conventions be rendered in the LNAB field as granados_marquez and becomes the unique profile ID. Not as Granados-67 but as Granados_Marquez-1

His children (Granados y Rey) would in the recommended naming conventions be rendered in the LNAB field as granados_rey by virtue of his marriage to Maria Concepcion Rey Capdevila

It is a string that is useless to match as each is rendered as a one string rather than two separate strings. Searches of the parent will not even find the children. Granados_Marquez and Granados_Rey being two different strings.

Typically (99% of the time) children adopt the paternal surname as their principle surname followed by the maternal surname. In my tree there are two instances where this has not been the case and the children have adopted the maternal surname as the principal surname followed by the paternal surname or dropping the paternal surname altogether. The maternal surname in each case being considered the more prestigious.

I do strongly support the concept of accommodating both paternal and maternal surnames in the Spanish way.  I'm less sure about the addition of more fields specific to this use case to do this.  As I went about this myself intuiting where things should go I found the paternal surname or principal surname was perfectly suited for the LNAB field. In the one case where I've added a profile where the person adopted the maternal surname as the principal surname I used this as the LNAB.

I wonder if the OLN isn't already the intuitive solution to this problem.  Simply that the rule set governing the usage of the field isn't robust enough. In the default setting the rule could continue to display an alternate or variation so as not to break the existing usage but could also benefit from some buttons to engage a different rule sets for the display of the name and in search and match functions. For the purposes of this thread to indicate the naming convention is Spanish. I can also see that other rule sets could be added to govern alternate languages and alphabets (such as Cyrillic or Mandarin); additional last names for women that are neither the birth or current last name (a woman who lived as and was known by the last name of the second of three husbands) or certain hyphenated names.

The Wikitree naming convention could then be amended to indicate the LNAB is the principal surname (either Paternal [most often] or Maternal) The profile creator would know this best.  OLN field could hold the Other Last Name with a button to engage a Spanish Naming Convention that would drop the "aka" and possibly add a "y" or possibly a variety  of use options like a button for Hispanic Standard and a drop down define specifics ( use "y"; name order; Spain, Mexico, Brazil)

Could this be the solution we are looking for?

by Michael Granados G2G Crew (800 points)
selected by SJ Baty

I think this proposal will also work.

If it is implemented it should also support displaying both last names without any separator, as in "Pau Gasol Sáez" (not "Pau Gasol y Sáez").  Currently most people in Spain do not use the "y" between last names.

"Evidently the best solution arrived at is to put both surnames in the LNAB field on the grounds that the both names are really one name.  This is incorrect and highly misleading.  It is not intuitive and no database best practise would be to put two pieces of different data in the same field.  The paternal surname and maternal surname are separate pieces of information and are unique to the individual person profile. They are not repeatable in the parents or children of any given person about would only repeat in the siblings of the person."


You just nail it with this paragraph.
Following up on this question:

I'm starting to enter some profiles with Spanish surnames and I see the following problems:

* Putting two surnames into one field creates a new and unique surname that doesn't exist in the real world.

* Using only the first surname excludes the second (maternal) surname.

To that end, I am beginning to think, regarding the second point, "so what?"  The maternal surname is dropped in the next generation anyways.  I am beginning to think that the way to go is to ONLY use the paternal surname as the LNAB and then use the paternal and maternal as the OLN.
That won't work for Colonial New Mexico where "father's last name Mother's last name" is very fluid, especially for the women.  Sometimes they only use the mother's name and sometimes they will use a family name, such as a maternal grandmother's last name.  The daughter of Diego de Trujillo and Catalina Marquez Vasquez mainly used the name Maria Bernardina de Salas y Trujillo but occasionally used de Salas y Orozco or just de Salas.  With the exception of Trujillo, the other three names most likely came from ancestors 2 or 3 or even 4 generations back. This is unusual but definitely not rare.
+2 votes

Hi Óscar,

Welcome to G2G.

I also have Spanish roots and I have found that the usage of names

  • Given Name + Paternal Last Name + Maternal Last Name

Is a relatively modern practice, starting on the XX century.

As soon as you get into source documents of your ancestors in the XIX century - 3 or 4 generations back - you'll find the names with no Maternal Last Name, only the Paternal Last Name was used.

Best of luck in your research.

by Rubén Hernández G2G6 Pilot (657k points)
Thanks, I didn't know that.  I have been searching and it looks like the use of 2 surnames generalized in 1850.

Anyway I hope WikiTree team can add the "Second Last Name" field to support the millions of people which have or had it.
I don't think this is quite correct.  Two last names (paternal and maternal) evolved as common naming practice in the late medieval period and was certainly well established by 1500. I've got paternal and maternal names consistently in my tree going back that far.
Agree - this has been going on for centuries.

If someone sees documents from two centuries past that don't have the maternal last name, the name was probably used in practice but was not recorded on the documents at the time.
+2 votes

I am trying to think through the implications of adding a "Second Last Name at Birth" box.  But I cannot think through all the possible unintended consequences of making such a change, given that it is not just Spanish that is involved here.

My conclusion is that, if it is a problem that Wikitree gives the wrong prompt for "Last Name at Birth", then, rather than try to automate it, it could be better to stop prompting and put the onus on the user to make the correct choice - and call it "Last Name(s) at Birth" (and maintain it as a "required" field of course).


by Tony Varey G2G Crew (590 points)
For profiles with an empty "Second Last Name" everything should behave as it currently does.  For profiles with a "Second Last Name", they should be displayed with 2 last names, and with links to both last names genealogies.  So this will not break anything.

Your proposal does not fix the problem because we have 2 last names, not just one double/composite last name.  If the data structure does not support 2 last names then we will always face problems in one way or another.
Further complicating the matter it would be needed to have a selection for name order as the convention is not strictly adhered too.

In my tree there are 2 occasions where the children opted for the more prestigious maternal surname as the principle surname.
You are saying this based on the idea that the double last name is one last name.  It is not.  John, son of Mark Smith and Jenny Collins, who becomes John Simth Collins - his surname isn't Smith Collins.  You can't just introduce Smith Collins as a surname and keep the actual LNAB.

There isn't a LNAB.  There is a LPNAB & LMNAB (last paternal/maternal name at birth).

A change could easily be coded - the 2nd LNAB could even be greyed out and not allowed to be filled in unless a box checked or some other safeguard to prevent use by folks who are confused.
Sounds well thought-through!
It's certainly an idea I would support.

Related questions

+3 votes
1 answer
+13 votes
2 answers
194 views asked Jul 16, 2015 in Policy and Style by Brandon Masterson G2G1 (1.4k points)
+9 votes
4 answers
198 views asked Jul 10, 2015 in Policy and Style by Gary Kueber G2G5 (5.1k points)
+6 votes
12 answers

WikiTree  ~  About  ~  Help Help  ~  Search Person Search  ~  Surname:

disclaimer - terms - copyright