ucfirst(strtolower($name)) rompe los nombres, y se puede medir

Todo pipeline de tratamiento de nombres acaba topándose con una fuente que grita. Los registros nacionales almacenan los nombres en mayúsculas — MCKENZIE, O'BRIEN, NGUYEN VAN NAM — porque los sistemas de los que proceden no conocían las minúsculas. En algún punto entre ese fichero y su interfaz de usuario, alguien tiene que decidir dónde van las mayúsculas.

El one-liner al que todo el mundo recurre es este:

$name = ucfirst(strtolower($name));       // PHP
name = name.title()                       // Python — same class of bug, different shape
name[0].toUpperCase() + name.slice(1).toLowerCase()   // JS

Produce Mckenzie, O'brien, Van Der Berg y Tôn-nữ. Los cuatro son erróneos. No «inusuales» — erróneos, en el sentido de que ningún registro, ninguna guía de estilo y ningún portador los escribe así.

Lo sabemos porque nosotros mismos publicamos dos de ellos. Esta página trata de cómo detectar el artefacto en datos que usted ya tiene, por qué la corrección evidente también es errónea, y dónde está el límite honesto de todo el ejercicio.

La firma: una frontera que se dispara cero veces

El indicio revelador no es que un nombre parezca raro. Los nombres parecen raros. El indicio revelador es un carácter de frontera que no produce ni una sola mayúscula en todo un fichero.

Este es nuestro corpus francés de nombres de pila, construido a partir del registro nacional de nombres de nacimiento. Contamos cada guion y cada apóstrofo dentro de un nombre y preguntamos qué clase de letra viene detrás:

2.884 guiones, todos y cada uno seguidos de una mayúscula: Jean-Pierre, Marie-Claire, Anne-Sophie. 54 apóstrofos, ni uno solo seguido de mayúscula.

Eso no es un hecho lingüístico sobre el francés. Es una firma de máquina. Aquello que rehízo la caja de este fichero trató - como frontera de palabra y ' como una letra corriente. Un transcriptor humano produce una mezcla; una regla produce una columna de ceros.

Lo que contienen en realidad las entradas con apóstrofo:

M'hamed  M'barek  M'baye  N'guessan  N'diaye  N'deye  N'faly  R'kia      ← correct as-is
O'bryan  O'neal   O'brian  O'neil   O'neill   Jo'anna  Carol'ann  Lou'ann ← wrong

Y por eso el defecto sobrevive a la revisión. La mayoría de esos nombres — el árabe M'hamed, los africanos occidentales N'diaye, N'guessan — están correctamente en minúscula tras el apóstrofo. Los rotos se esconden entre ellos. Quien recorre el fichero con la vista ve una mezcla plausible de nombres magrebíes y sahelianos, y sigue adelante.

Compare con un fichero cuya caja no se rehízo mecánicamente. En el conjunto de los 64 locales que publicamos, esto es lo que sigue a un apóstrofo:

en_NZ es la fila interesante y la que zanja el argumento a favor de una regla mecánica. Contiene las dos convenciones, ambas correctas: el irlandés O'Brien pone mayúscula tras el apóstrofo, y los samoanos Su'a, Fa'alogo, Fepulea'i, Papali'i no la ponen, porque allí el apóstrofo es una consonante oclusiva glotal (el ʻokina), no una frontera de palabra. Un fichero, un país, dos reglas opuestas, y ninguna manera de decidirlo a partir de la cadena.

Los dos que hicimos mal

en_IE: Mckeever → McKeever. Sencillo, detectado y corregido.

vi_VN: Tôn-nữ → Tôn Nữ y Tôn-thất → Tôn Thất. Corregido el 21 de julio de 2026, y vale la pena explicarlo, porque el argumento de que se trata de un fallo — y no de una variante ortográfica legítima — es estructural, no estético.

Los apellidos compuestos vietnamitas solo han tenido dos normas escritas:

La segunda sílaba de un nombre propio vietnamita lleva mayúscula en las dos. Nunca ha existido una norma en la que vaya en minúscula. Tôn-nữ no es, por tanto, ni un arcaísmo, ni una variante regional, ni una grafía de la fuente: es exactamente lo que emite ucfirst(strtolower("TÔN-NỮ")). Dos normas conocidas, y la cadena no coincide con ninguna de las dos: ese es un argumento más fuerte que «a mí me parece mal».

Elegimos la forma con espacio en lugar de Tôn-Nữ porque el resto del corpus vietnamita ya usa espacios para las unidades plurisilábicas — 49 nombres de pila separados por espacio en el fichero masculino, 79 en el femenino, y cero guiones en ningún nombre vietnamita. Estado actual: Tôn Nữ (puesto 122, peso 17) y Tôn Thất (puesto 147, peso 12) de 298 apellidos, sin ningún guion restante.

Después barrimos los 64 locales en busca del mismo patrón — guion seguido de letra minúscula — y encontramos tres supervivientes:

Tres coincidencias, y la regla automática habría «corregido» las tres convirtiéndolas en errores.

El más grande, que no hemos corregido: 158 nombres de pila

Los apellidos de nuestros locales ingleses están limpios. Los nombres de pila no, y las cifras dicen exactamente dónde se detuvo la frontera de la limpieza:

Cero en toda la línea — en los ficheros de apellidos. En los ficheros de nombres de pila de en_US hay 158 entradas que empiezan por Mc + minúscula, que suman 148.225 de un peso de 282.696.333 (0,052 %): Mckenzie (55.094), Mckenna (36.825), Mckayla (11.415), Mckinley (9.468).

La prueba de que se trata de un artefacto del pipeline y no de dos convenciones de denominación distintas es que las mismas cadenas aparecen en ambos ficheros, con mayúsculas distintas, dentro del mismo corpus:

Veinte colisiones de este tipo. La misma población de origen, la misma organización, dos decisiones de caja distintas — porque un fichero pasó por una lista de excepciones elaborada a mano y el otro pasó por ucfirst.

La fuente está en mayúsculas, y ya ha tirado cosas

Conviene saberlo antes de escribir su conversor de caja: el registro cuya caja está rehaciendo puede haber destruido algo más que la caja.

Los dos productos de nombres del censo estadounidense de 2020 almacenan los nombres en mayúsculas, y contamos lo que hay en ellos:

El Census Bureau no se limita a poner los nombres en mayúsculas; elimina el apóstrofo por completo. O'Brien se publica como OBRIEN. Así que el O'Brien de peso 115.547 de nuestro corpus no es un dato de la fuente: es una reconstrucción, hecha por alguien que sabía que OBRIEN es O'Brien y no Obrien. Esa reconstrucción es conocimiento, no transformación, y ninguna firma de función puede codificarla.

Es el mismo esquema que la supresión de tildes en los registros españoles: el registro normaliza para su propia comparabilidad, y la normalización es irreversible sin conocimiento externo.

Por qué ucfirst y ucwords no tienen arreglo

La tentación, después de ver todo esto, es escribir una versión mejor: partir por -, ', , y poner cada trozo en mayúscula inicial. Eso produce M'Hamed, N'Diaye, Su'A, Papali'I, Van Der Berg, De La Cruz, Al-Ahmad. Ha cambiado un error uniforme por otro.

Hay cuatro problemas distintos apilados unos sobre otros, y solo el primero tiene que ver con las fronteras de palabra.

1. El conjunto de caracteres de frontera no es [ -]. Como mínimo necesita -, ', ’ (U+2019, que los datos reales contienen junto a U+0027), el espacio y el . de las iniciales. ucfirst no maneja ninguno. ucwords maneja el espacio y, en PHP, recibe una lista explícita de delimitadores precisamente porque no existe un valor por defecto correcto.

2. No todo carácter de frontera es una frontera. Lo establecen los datos anteriores: el apóstrofo es una frontera en O'Brien y una consonante en Su'a; el guion es una frontera en Jean-Pierre e interno en Karo-karo. El mismo carácter, en el mismo fichero, significa dos cosas.

3. Algunos elementos deben permanecer en minúscula, y cuáles son depende de la lengua. Los neerlandeses van, de, van der, ten van en minúscula detrás de un nombre de pila y en mayúscula sin él — una regla de posición, no una grafía fija. El neerlandés de Bélgica congela lo que haya consignado el registro civil, de modo que De Smet es De Smet en todas partes. El árabe bin, bint, al-; el portugués dos, da; el francés de, du; el alemán von, zu — cada uno tiene su propia convención, y aplicar la neerlandesa a un nombre belga, o la alemana a uno portugués, produce un error real en ambos sentidos.

4. El propio strtolower es incorrecto para algunas escrituras. strtolower en PHP trabaja sobre bytes y estropea el UTF-8 (mb_strtolower es el mínimo). El turco tiene una i con punto y otra sin punto: İSTANBUL pasa a istanbul en minúsculas solo bajo un locale turco, y a i̇stanbul en cualquier otro caso. La sigma final griega cambia de forma según su posición. Y en georgiano — que publicamos — el mkhedruli no tiene caja en absoluto; un barrido ingenuo en busca de «nombres que empiezan por minúscula» marca como sospechosas las 1.036 entradas georgianas, y todas ellas están bien.

La lista de excepciones es obligatoria, y depende de la lengua

No puede evitar una lista. Mc, Mac, O', Fitz, van, de, von, bin, al-, Ó, Ní, Le, D'. De acuerdo — salvo que la lista tampoco divide limpiamente los datos, y nuestro corpus contiene los contraejemplos:

Así que la lista tiene que ser una lista de nombres, no de prefijos. Lo que significa que hay que construirla a partir de una fuente que consigne las grafías reales, que es justamente lo que usted no tenía cuando empezó.

Y luego está Macdonald

El caso genuinamente irresoluble, y preferimos decirlo con claridad antes que dejarle creer que existe una lista lo bastante buena.

Macdonald y MacDonald son dos apellidos igual de reales, llevados por familias distintas, y no son variantes el uno del otro más de lo que lo son Smith y Smyth. En nuestro corpus británico, la forma con minúscula medial reúne 21.737 portadores; en nuestro corpus estadounidense, la forma con mayúscula medial reúne 45.126. Ninguna es una errata de la otra. No hay ninguna regla — ni de locale, ni de frecuencia, ni de escocés frente a irlandés — que decida cuál de las dos corresponde a una persona dada.

Lo mismo vale para Mackenzie / MacKenzie / McKenzie, y para Vandenberghe frente a Van den Berghe en los datos belgas, donde la forma fusionada y la separada son apellidos legalmente distintos que pertenecen a familias distintas.

Cualquier normalización que haga corresponder estas formas entre sí destruye personas reales. Ese es el techo de todo este problema: no «difícil de automatizar», sino que no existe respuesta correcta como función de la cadena.

Lo que sí funciona

1. No rehaga la caja en absoluto si puede evitarlo. Si la fuente viene en caja mixta, consérvela byte a byte. Toda transformación es una ocasión de perder algo, y ninguna transformación añade información.

2. Si tiene que rehacer la caja de una fuente en mayúsculas, trátelo como una reconstrucción, no como un formateo. Una reconstrucción necesita pruebas: una segunda fuente en caja mixta, una lista elaborada a mano, o una persona. Presupueste en consecuencia, y deje constancia de qué filas se reconstruyeron.

3. Audite con la prueba de frontera, no leyendo. Para cada carácter de frontera, cuente cuántas veces le sigue una mayúscula y cuántas una minúscula, fichero por fichero. Una columna de ceros puros en cualquiera de los dos sentidos es una máquina, no una lengua. Esta prueba encontró nuestros tres defectos y costó una docena de líneas de código.

4. No rehaga nunca la caja en la salida. Si su plantilla llama a una función de puesta en mayúsculas al representar un nombre, ha desplazado el fallo al punto donde es menos visible y más difícil de probar. Normalice una sola vez, en la ingesta, deliberadamente, y almacene el resultado.

5. Valide según se pueda mostrar, no según la forma. ^[A-Z] como regla de validación de un nombre rechaza dela Cruz — el apellido más frecuente de Filipinas — y da Silva, que figuran ambos en nuestro corpus como entradas correctamente con inicial minúscula, y rechaza todos los nombres georgianos jamás escritos.

6. Separe las mayúsculas de visualización de las mayúsculas almacenadas. Un apellido representado solo — en un índice ordenado, en una columna de tabla, en un saludo — puede necesitar legítimamente unas mayúsculas distintas de las del mismo apellido colocado detrás de un nombre de pila. Eso es una función de representación con un argumento de locale, no una propiedad de la cadena almacenada.

Limitaciones conocidas

• No hemos corregido los 158 nombres de pila Mc* de en_US. Son el 0,052 % del peso de los nombres de pila, y corregirlos supone decidir, nombre por nombre, si Mckenzie como nombre de pila es un McKenzie mal puesto en mayúsculas o una grafía moderna distinta que los padres registran realmente — y en los nombres de pila, a diferencia de los apellidos, la segunda lectura es genuinamente plausible.
• Jo-anne en en_NZ está sin resolver. Tanto Jo-anne como Jo-Anne están atestiguados. Hemos conservado la grafía de la fuente.
• Las entradas con apóstrofo de fr_FR están sin corregir. Podemos identificar O'bryan, O'neal y O'brian como artefactos con seguridad; no podemos separarlos mecánicamente de los cuarenta y tantos nombres magrebíes y africanos occidentales correctamente en minúscula del mismo fichero, y no se ha tomado ninguna decisión nombre por nombre.
• Hemos medido nuestro propio corpus, no el mundo. Los recuentos de -/', los inventarios de prefijos y las colisiones entre nombres de pila y apellidos son todos mediciones de los ficheros que publicamos, tomadas el 21 de julio de 2026. Son evidencia sobre cómo se comporta esta clase de fallo, no un censo de ella.

Datos actualizados a 2026-07-21

64 locales analizados. Apellidos vi_VN: 298 entradas, 99.441 de peso total, 0 guiones, Tôn Nữ y Tôn Thất en la forma corregida; ficheros masculino y femenino idénticos byte a byte. en_US: 2.064 apellidos y 53.618 filas de nombres de pila en la fuente. Ficheros del censo estadounidense de 2020 contados directamente. Todas las cifras se han recalculado para esta página, en lugar de citarse de notas anteriores.

Fuentes

• US Census Bureau — Frequently Occurring Surnames from the 2010/2020 Census
• Manual de PHP — ucwords(), por qué la lista de delimitadores es explícita
• Unicode Standard Annex #21: Case Mappings
• W3C — Personal names around the world