Discusión de plantilla: Nihongo

Error menor con la representación de la vista previa

He notado un pequeño error en la forma en que interactúan las vistas previas de páginas de MediaWiki y esta plantilla. Se pueden ver dos casos del error en la vista previa al pasar el mouse sobre este enlace: Kyoto Animation . Si la llamada de plantilla está seguida por una coma, se genera un espacio adicional en el medio.

¿Alguna idea de cómo solucionarlo? — Goszei ( discusión ) 00:00, 3 de diciembre de 2020 (UTC) [ responder ]

No estoy convencido de que el "problema" sea culpa de esta plantilla. Compare el texto real de la primera línea de Kyoto Animation con la primera línea de texto de la ventana emergente:

Kyoto Animation Co., Ltd. (japonés: 株式会社京都アニメーション, Hepburn: Kabushiki-gaisha Kyōto Animēshon), a menudo abreviado KyoAni (京アニ, Kyōani), es...
Kyoto Animation Co., Ltd., a menudo abreviada como KyoAni, es...

Se ha eliminado el texto entre paréntesis. Cada paréntesis va precedido de un espacio y seguido de una coma. Sospecho que la ventana emergente no sabe qué hacer con la plantilla, por lo que conserva todo lo que había a su alrededor.

—El monje trapense ( discusión ) 00:35 3 dic 2020 (UTC) [ responder ]

@Trappist the monk: Hm... las plantillas "lang-xx" y "zh" lo representan correctamente, sin embargo; vea las ventanas emergentes para la Armada Francesa y la Dinastía Shang . Creo que el analizador está confundido por cómo (a diferencia de esas plantillas) Nihongo también genera los paréntesis, en lugar de solo la información dentro de ellos.

Tal vez esto se pueda solucionar haciendo que el analizador ignore de alguna manera el "espacio" generado dentro de la plantilla. — Goszei ( discusión ) 01:42 3 dic 2020 (UTC) [ responder ]

Comparar el marcado sin procesar:

Animación de Kioto :
{{Nihongo|'''Kyoto Animation Co., Ltd.'''|株式会社京都アニメーション|Kabushiki-gaisha Kyōto Animēshon|lead=yes}}, often...
Marina francesa :
The '''French Navy''' ({{lang-fr|Marine nationale|lit=National Navy}}), informally "{{lang|fr|La Royale}}", is...
Dinastía Shang :
The '''Shang dynasty''' ({{zh|c={{linktext|商朝}}|p=Shāngcháo}}), also

Los paréntesis se crean en Kyoto Animation, mientras que los paréntesis se colocan manualmente en la Armada francesa y la dinastía Shang. Sin embargo, aquí hay un ejemplo que muestra el problema pero no utiliza una plantilla:{{nihongo}}

USS Benjamin Franklin . El precio bruto es:
'''USS ''Benjamin Franklin'' (SSBN 640)''', the...

La ventana emergente eliminó el paréntesis que designaba el casco, pero conservó el espacio y la coma. Esto es más o menos lo mismo, no tiene una coma al final y no presenta el problema:

USS Will Rogers (SSBN-659)
'''USS ''Will Rogers'' (SSBN-659)''' was...

Todavía no estoy convencido de que el problema esté en {{nihongo}}... si así fuera, Benjamin Franklin no presentaría el problema...

—El monje trapense ( discusión ) 02:19 3 dic 2020 (UTC) [ responder ]

¿"No utilizar el parámetro 'lead' en artículos biográficos"?

A mí me parece que esto es algo obvio, pero ¿es algo obvio para el resto? Si no, ¿qué opinan de mi razonamiento? ¿Deberíamos hacer un rūru-ka si no lo hemos hecho ya? Hijiri 88 (聖やや) 20:00, 31 de diciembre de 2020 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 20 de marzo de 2021

Para agregar un orden de formato de salida adicional para los argumentos de la plantilla, me gustaría solicitar la fusión del código que propongo en la página Módulo:Nihongo krt.

Para hacer tal cosa, he creado una página de plantilla: Plantilla:Nihongo krt para generar en el formato: KANJI/KANA (ROMAJI, INGLÉS, EXTRA) EXTRA

Dado que la sintaxis es la misma que la de las plantillas existentes para Nihongo y Nihongo3, esto proporciona una opción adicional para que los editores presenten el texto en japonés de manera consistente en los artículos.

¿Por qué necesitamos otro formato?

Actualmente, el formato se centra en el "inglés" primero (T:Nihongo) o en el "rōmaji" primero (T:Nihongo3). Sin embargo, en las páginas de lingüística que analizan la pronunciación y las conjugaciones de palabras japonesas, necesitamos que los kanji/kana sean el foco principal dentro de este contexto (ya que no se pueden diferenciar patrones lingüísticos con rōmaji, ya que rōmaji no discrimina kanji). Por lo tanto, para el contexto de la pronunciación y las conjugaciones, necesitamos una plantilla sencilla que coloque los kanji primero con una guía rápida de pronunciación de rōmaji al lado. En muchos casos, para estos artículos, el significado semántico de las palabras tampoco es relevante, por lo que no necesitamos atiborrar el texto con una traducción al inglés de cada una.

El código ya está funcionando, pero sería más sinérgico si se fusionara en un solo módulo en lugar de tener módulos concurrentes casi idénticos haciendo lo mismo. JKVeganAbroad ( discusión ) 17:55, 20 de marzo de 2021 (UTC) [ responder ]

¿Por qué necesitamos otro formato? No tengo una opinión, puede que otros sí la tengan.

La documentación de sugiere que esa plantilla es incoherente con , y . Esa elección me parece equivocada. Los editores suelen equivocarse en el orden de los parámetros con estas plantillas, por lo que creo que es importante que toda la familia nihongo mantenga un orden de parámetros coherente. Dado que estoy hablando de coherencia, el nombre de la plantilla probablemente debería ser (¿qué significa la "t"?){{Nihongo krt}}{{nihongo}}{{nihongo3}}{{nihongo foot}}{{nihongo krt}}

¿No hay casos de prueba ? ¿Cómo sabemos que la plantilla funciona como debería?

—El monje trapense ( discusión ) 18:55 20 mar 2021 (UTC) [ responder ]

Hola, monje trapense. ¡Gracias por leer esta propuesta y el código! Para abordar tus puntos:

1. Al principio, iba a convertirlo en un módulo independiente, pero después de pensarlo, cambié de opinión durante la codificación (llegué a las mismas conclusiones que mencionaste sobre los editores que confunden el orden de los parámetros). De hecho, la plantilla se volvió a codificar para que (sí, de hecho) sea compatible con , , y , con los parámetros en las mismas posiciones.{{nihongo}}{{nihongo3}}{{nihongo foot}}

Pensé que había corregido la documentación para reflejar esto, pero me perdí algunas secciones (era tarde por la noche para mí, lo siento). He corregido la documentación como tal (lo siento por el problema).

2. Ya que estoy hablando de consistencia, el nombre de la plantilla probablemente debería ser (en lugar de ) {{nihongo krt}}{{nihongo-krt}}

En cuanto a esto, no estoy familiarizado con las convenciones de nombres existentes, por lo que confío en tu sugerencia y la apoyo. Ya he realizado esos cambios y he redirigido las URL en esta discusión hacia este nuevo nombre.

3. ¿Qué significa la "t"? "t" significa "traducción". Tal vez podría ser "e" para inglés, pero quería que la plantilla fuera compatible con otros idiomas de Wikipedia. No estoy seguro de la validez de mi juicio en este caso.

4. He creado una página de casos de prueba , gracias por el consejo.

Gracias de nuevo por tus críticas constructivas hasta el momento. ¿Tienes alguna otra idea que podamos aprovechar?

JKVeganAbroad ( discusión ) 06:51 21 mar 2021 (UTC) [ responder ]

Salvo lo claramente obvio, los casos de prueba parecen ser correctos.

—El monje trapense ( discusión ) 11:42 26 mar 2021 (UTC) [ responder ]

Son excelentes noticias. Module:Nihongo krt es una bifurcación de la versión actual de Module:Nihongo , por lo que, suponiendo que nadie se oponga a esta incorporación, ¿debería seguir adelante y modificar Module:Nihongo/sandbox para asegurar que los otros casos de prueba ( casos de prueba Nihongo , casos de prueba Nihongo3 , casos de prueba Nihongo foot ) produzcan resultados idénticos?

JKVeganAbroad ( discusión ) 13:41 26 mar 2021 (UTC) [ responder ]

Podrías hacerlo; después de todo, para eso están los sandboxes.

Supongo que lo que para mí es evidente, no lo es tanto para ti.

—El monje trapense ( discusión ) 14:06 26 mar 2021 (UTC) [ responder ]

De hecho, si hay un problema evidente, no lo he notado. ¿Cuál es el problema?

Intentaré modificar el sandbox principal más tarde esta noche.

JKVeganAbroad ( discusión ) 05:17 27 mar 2021 (UTC) [ responder ]

SEGUIMIENTO: ¿Es obvio que el mensaje de error es reciclado de Nihingo3?

Si es así, es porque necesito ayuda para implementar un mensaje de error adecuado, ya que parece que a partir del código el manejo de mensajes de error no está contenido dentro del código del Módulo:Nihongo , y está subcontratado a algún otro script en Wikipedia... No sé dónde está.

JKVeganAbroad ( discusión ) 05:31 27 mar 2021 (UTC) [ responder ]

He corregido el mensaje de error. Al principio, leí mal el código, pero después de volver a leerlo, el código del mensaje de error no era nada complicado. Supone el mismo error para todas las plantillas y la única variante es el título de la plantilla.

De todos modos, he reemplazado el código en el módulo: Nihongo/sandbox y todos los casos de prueba de sandbox ( casos de prueba de Nihongo , casos de prueba de Nihongo3 , casos de prueba de Nihongo foot , casos de prueba de Nihongo krt ) son idénticos a los casos de prueba en vivo. Parece que el código está listo para fusionarse. JKVeganAbroad ( discusión ) 12:00, 27 de marzo de 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 20 de marzo de 2021

Para agregar un orden de formato de salida adicional para los argumentos de la plantilla, me gustaría solicitar la fusión del código que propongo en la página Módulo:Nihongo krt.

He creado una página de plantilla: para generar la salida en el formato: KANJI/KANA (ROMAJI, TRADUCCIÓN (inglés), EXTRA) EXTRA{{Nihongo krt}}

Esto es como , excepto que va seguido de información adicional entre paréntesis.{{Nihongo2}}

(Alguien cerró esta solicitud de edición porque "aún no hay una solicitud específica aquí con consenso", así que supongo que debo crear esta nueva solicitud ahora que he abordado las inquietudes).

JKVeganAbroad ( discusión ) 01:49 22 mar 2021 (UTC) [ responder ]

Soporte . Es bueno que los órdenes de los parámetros en esta nueva plantilla coincidan con las otras plantillas de Nihongo. Sería bueno si todas las plantillas pudieran simplificarse a solo una que use un parámetro de orden, pero ese es un proyecto para otro día. — Goszei ( discusión ) 01:45, 23 de marzo de 2021 (UTC) [ responder ]

hecho

—El monje trapense ( discusión ) 13:01 27 mar 2021 (UTC) [ responder ]

¡Muchas gracias! -- JKVeganAbroad ( discusión ) 14:05 27 mar 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 30 de mayo de 2021: problemas de kerning

El módulo Nihongo aplica automáticamente el formato de cursiva al texto rōmaji. Sin embargo, en tres casos seleccionados en los que el rōmaji toca el corchete de cierre del paréntesis, surgen problemas de interletraje. Esto significa que las letras en cursiva se representan de manera tal que el carácter final se superpone con el carácter de cierre del paréntesis, lo que puede generar problemas de accesibilidad y lectura.

Wikipedia recomienda utilizar un  carácter en estas situaciones para corregir problemas de kerning y mejorar la legibilidad. Muchos editores pueden no notar el problema o no saber cómo corregirlo manualmente. Además, hacerlo manualmente es costoso para el tamaño de página en páginas que usan cientos de módulos nihongo (por ejemplo, si se aceptara esta propuesta de fusión, la conjugación de verbos japoneses se reduciría en 1400 bytes al eliminar los 200  códigos que hay actualmente).

Propuse una modificación al código del módulo Nihongo para incluir automáticamente un  en los tres casos en los que es probable que surjan problemas de kerning. Puede notar la diferencia en los casos de prueba 69 y 70 de nihongo y el caso de prueba 46 de nihongo krt (nihongo3 y nihongo foot no se ven afectados por problemas de kerning).

Dado que agregar el  es invisible, solo entre tres casos de sintaxis, mejora la visibilidad y accesibilidad de la salida formateada, dudo que esto genere objeciones en la comunidad.

Un cordial saludo, JKVeganAbroad ( discusión ) 15:12 30 may 2021 (UTC) [ responder ]

En mi máquina con mi navegador (versión actual de Chrome)  se representa aproximadamente el mismo ancho que un carácter de espacio genérico, por lo que el desplazamiento entre el carácter en cursiva final y el paréntesis de cierre es objetablemente amplio (especialmente cuando el carácter en cursiva no está en negrita); cf:

l ) ← ''l'')– sin espacio

l ) ← ''l'')– espacio genérico

l ) ← ''l'')– 

y cuando está en negrita:

l ) ← '''''l''''')– sin espacio

l ) ← '''''l''''')– espacio genérico

l ) ← '''''l''''')– 

Quizás una mejor solución sea CSS:

l ) ← ''l'')– css

l ) ← '''''l''''')– css

—El monje trapense ( discusión ) 15:43 30 may 2021 (UTC) [ responder ]

He estado usando Firefox, pero no pude reproducir el problema en Chrome ni en otros navegadores de mi equipo. Estoy usando macOS, por lo que podría ser un problema de representación con el código en Chrome para Windows o Linux, o algún otro tipo de interferencia.

Pero de todas formas, me gusta mucho tu solución por dos razones:

1) Probablemente resuelva el problema en su máquina y, por lo tanto, también en las máquinas de otras personas, y

2) No agrega un molesto espacio extra si las personas intentan copiar y pegar el romaji, por lo tanto no introduce interferencias de caracteres.

Implementé tu sugerencia en el entorno de pruebas y los casos de prueba se procesan perfectamente en todos mis navegadores y dispositivos (¡gracias!). ¿Se procesan correctamente en tu dispositivo?

— JKVeganAbroad ( discusión ) 00:53 31 may 2021 (UTC) [ responder ]

Implementado — Martin ( MSGJ · discusión ) 11:11 7 jun 2021 (UTC) [ responder ]

Eres una leyenda, ¡gracias! — JKVeganAbroad ( discusión ) 12:12 7 jun 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 7 de junio de 2021: problemas de kerning

Esto es incómodo. Básicamente por las mismas razones que la solicitud de edición anterior, propongo esta modificación al código del módulo Nihongo para usar CSS automáticamente mediante la inclusión (para evitar 6 casos marginales donde el formato de cursiva del texto rōmaji causa problemas de kerning. Específicamente, estos son visibles en los casos de prueba 69 y 73 de nihongo y los casos de prueba 44, 46, 47 y 48 de nihongo krt (nihongo3 y nihongo foot no se ven afectados por problemas de kerning). Observe cómo la letra "j" toca el primer corchete de apertura del paréntesis. Las letras "y" y "p" también se ven afectadas de esta manera. El objetivo es mejorar la visibilidad y accesibilidad de la salida formateada. Atentamente, JKVeganAbroad ( discusión ) 13:13, 7 de junio de 2021 (UTC) [ responder ]

Me lo pregunté cuando hice la otra solicitud de edición, pero no lo dije. ¿No sería mejor aplicar este kerning solo cuando sea necesario en lugar de hacerlo siempre, independientemente de la necesidad? Por lo tanto, solo aplique kerning a las letras minúsculas iniciales que tengan un descendente [jpy] que toque el paréntesis y a las letras mayúsculas o minúsculas finales con un ascendente que toque el paréntesis [dfklt] [EFHIJKMNTUVWXYZ].

minúsculas con descendentes:

( g – no necesita kerning
( yo
( pag
( q – no necesita kerning
( y

minúsculas con ascendentes:

b ) – no necesita kerning
d )
F )
h ) – no necesita kerning
i )
y )
k )
yo )
( o )

minúsculas sin ascendentes ni descendentes:

a ) – no necesita kerning
c ) – no necesita kerning
e ) – no necesita kerning
m ) – no necesita kerning
n ) – no necesita kerning
o ) – no necesita kerning
o )
s ) – no necesita kerning
u ) – no necesita kerning
v )
el )
x )
y )

mayúsculas:

A ) – no necesita kerning
B ) – no necesita kerning
C ) – no necesita kerning – necesita kerning en mi sistema (JKVeganAbroad)
D ) – no necesita kerning
mi )
F )
G ) – no necesita kerning
H )
I )
Yo )
K )
L ) – no necesita kerning
METRO )
N )
O ) – no necesita kerning
P ) – no necesita kerning – necesita kerning en mi sistema (JKVeganAbroad)
Q ) – no necesita kerning
R ) – no necesita kerning – necesita kerning en mi sistema (JKVeganAbroad)
S ) – no necesita kerning – necesita kerning en mi sistema (JKVeganAbroad)
Yo )
tú )
V )
Yo )
X )
Y )
Z )

puntuación:

' )
" )
? )
! )
] )
) ) – no necesita kerning

—El monje trapense ( discusión ) 13:56 7 jun 2021 (UTC) [ responder ]

…¿No sería mejor aplicar este kerning solo cuando sea necesario en lugar de hacerlo siempre, independientemente de su necesidad?…

Hola, sí, por supuesto que tienes razón. En primer lugar, es un poco molesto aprender un nuevo lenguaje de programación, así que esta fue la "solución" más eficiente que se me ocurrió (es decir, la solución perezosa de "Bueno, si funciona..."). En segundo lugar, para ser honesto, no estoy exactamente interesado en investigar cómo hacerlo. Incluso si pudiera implementar algún tipo de sustitución a través de RegEx simple, realmente no entiendo ni sé cómo trabajar con variables en el lenguaje Lua (quiero decir, todas las variables son %s(¡¿qué demonios?!) ¿Por qué no son únicas? Jajaja Dios mío, por favor, ayuda ). Así que básicamente mis propias deficiencias son la razón por la que propuse esta solución alternativa. EDITAR: ~~No creo que sea terrible, sin embargo, dudo que alguien se dé cuenta~~ (además, incluso con esta solución creo que el espacio adicional es solo un poquito demasiado pequeño para la comodidad, pero al menos técnicamente no hay superposición).

¿Podrías ayudarme?

Por cierto, agregué algunos "casos de prueba" a la lista que proporcionaste y agregué algunos desacuerdos donde mi sistema (macOS, Firefox, más reciente) presenta superposición de kerning.

Saludos — JKVeganAbroad ( discusión ) 14:33 7 jun 2021 (UTC) [ responder ]

Espera un segundo.

Acabo de duplicar el espacio entre .1em0 y 1 .2emy se ve maravilloso. Mucho mejor para los corchetes de apertura y cierre.

PERO duplicar la brecha, que resuelve adecuadamente el problema, crea exactamente el problema que usted implícitamente anticipó: la brecha es notablemente demasiado grande en los casos donde los caracteres no la necesitan: vea los casos de prueba 3, 7, 25, 29, 49 y 53 de nihongo y los casos de prueba 5, 6, 7, 15, 16, 17, 25, 26, 27, 36, 37 y 38 de nihongo krt .

La solución que usted propone, sólo cuando es necesaria, es la solución que necesitamos. ¿Podría, por favor, prestarnos su experiencia, si es posible?

— JKVeganAbroad ( discusión ) 15:09 7 jun 2021 (UTC) [ responder ]

Para ello, eliminaré el kerning actual del entorno de pruebas. También configuraré esta solicitud de edición como respondida para evitar una actualización involuntaria del módulo activo. Si no encontramos una solución razonable, podemos restaurar el entorno de pruebas.

—El monje trapense ( discusión ) 15:31 7 jun 2021 (UTC) [ responder ]

Sí, buena idea. — JKVeganAbroad ( discusión ) 15:41 7 jun 2021 (UTC) [ responder ]

@Trappist the monk, la función que has añadido al sandbox funciona muy bien en los casos de prueba ( nihongo , nihongo krt ). ¡En el momento en que leí este código supe que eres Neo y que puedes leer Matrix! No puedo agradecerte lo suficiente por tu codificación.

Voto a favor de fusionar su propuesta. — JKVeganAbroad ( discusión ) 02:37 8 jun 2021 (UTC) [ responder ]

hecho.

—El monje trapense ( discusión ) 12:43 8 jun 2021 (UTC) [ responder ]

¡Gracias, mi héroe! — JKVeganAbroad ( discusión ) 12:50 8 jun 2021 (UTC) [ responder ]

Comentarios: ~~Creo que el espacio es demasiado para los casos que no necesitan kerning, como lo marcó Trappist arriba~~ (esto es un error, ver abajo) y todavía un poco demasiado para los casos que sí necesitan kerning. Al menos en mi navegador, parecía un espacio erróneo, que intenté eliminar. — Goszei ( discusión ) 01:46 10 jun 2021 (UTC)[ responder ]

Ah, ya veo el problema. En Hololive Production#History se aplica un espaciado al final de "Kabushiki-gaisha" porque está enlazado a una wiki, lo que no se toma como un caso para evitar el espaciado como si no estuviera enlazado. Esto también es un problema con otros tipos de marcado: en la conjugación de verbos japoneses se aplica a "kaban o motte iru" solo cuando "iru" está en negrita y el marcado está entre las letras y el paréntesis. No estoy seguro de si vale la pena arreglar el pequeño problema inicial de kerning si la solución debe volverse cada vez más Frankenstein. — Goszei ( discusión ) 01:52, 10 de junio de 2021 (UTC) [ responder ]

Creo que el espacio debe ser de 0,15 em como máximo, que es lo que aplican las plantillas de la familia Template:'" . — Goszei ( discusión ) 01:57 10 jun 2021 (UTC) [ responder ]

Gracias por los comentarios, y gracias aún más por identificarlo como un error causado al asumir que el marcado wiki es un carácter de texto.

En cuanto a tu opinión sobre que el máximo sea .15em, lo probaré en el sandbox.

Una consecuencia imprevista de la atención a los caracteres de puntuación. Una solución es eliminar los caracteres de puntuación de la prevención automática de superposición de interletraje, pero lo ideal sería mejorar el código para diferenciar el marcado wiki del texto de puntuación. Quizás pueda solucionar el error.

¡Deséenme suerte! — JKVeganAbroad ( discusión ) 13:23 10 jun 2021 (UTC) [ responder ]

ejemplo ( ejemplo ) ←{{Nihongo/sandbox|example||example}}
example (example)
ejemplo ( ejemplo ) ←{{Nihongo/sandbox|example||[[example]]}}
example ([[example]])
ejemplo ( ejemplo ) ←{{Nihongo/sandbox|example||'''example'''}}
example ('''example''')
ejemplo ( ejemplo ) ←{{Nihongo/sandbox|example||[[example|'''example''']]}}
example ([[example|'''example''']])
ejemplo ( ejemplo ) ←{{Nihongo/sandbox|example||'''[[example]]'''}}
example ('''[[example]]''')

—El monje trapense ( discusión ) 13:36 10 jun 2021 (UTC) [ responder ]

@Trappist el monje ya arregló el código, ¡qué campeón! Actualicé el sandbox para usar el .15em que sugeriste y me parece bien; no tengo objeciones. Apoyo el código actualizado propuesto. — JKVeganAbroad ( discusión ) 14:59 10 jun 2021 (UTC) [ responder ]

Buen arreglo. En mi navegador (Chrome), considero que .05em es suficiente para eliminar por completo el mal kerning. Los resultados pueden variar, pero .05 me parece el más natural, mientras que .1em y .15em definitivamente hacen que uno se sorprenda por ser "notable" y resaltar demasiado al leer. Yo abogaría por un valor de .05, o el más bajo que podamos alcanzar por encima de eso. — Goszei ( discusión ) 16:51 10 jun 2021 (UTC) [ responder ]

Sinceramente, 0,1 em no fue suficiente para mi sistema, así que me preocupa un poco que quieras que sea más delgado. ¿Hay alguna forma de ver lo que estás viendo? Es decir, ¿capturas de pantalla? Como referencia, estoy usando macOS, probé en Firefox, Chrome, Edge, Safari (el sistema operativo y el software son todas las versiones actuales). Además, Safari en particular parecía tener un espacio incómodamente más delgado que los otros navegadores (es decir, demasiado delgado con 0,15 em). — JKVeganAbroad ( discusión ) 17:25, 10 de junio de 2021 (UTC) [ responder ]

Aquí hay una captura de pantalla: [1] (ejecutando Chrome en Windows 10). Supongo que también es una cuestión de gusto personal, pero creo que 0em se ve raro, .05em se ve más natural, que 0.1 es demasiado y que .15 es demasiado, y se acerca a mi cerebro leyendo eso como "un espacio errante". "Eliminar por completo" fue una exageración, a juzgar por la "f" en particular, pero en general creo que es lo más aceptable. ~~Hice esta captura de pantalla en mi sandbox ( Special:Permalink/1027919750 ), inspeccioné la página y cambié los valores manualmente.~~ Aquí hay una versión que se puede usar para comparar: Special:Permalink/1027922382 . — Goszei ( discusión ) 19:32, 10 de junio de 2021 (UTC) [ responder ]

También solicité capturas de pantalla a los usuarios de WP:DISCORD , y así es como se ven: [2] [3] [4] [5]. — Goszei ( discusión ) 20:06 10 jun 2021 (UTC) [ responder ]

Gracias por esas capturas de pantalla de colaboración colectiva. Ahora entiendo cuál es el problema. Las fuentes son diferentes, si comparamos el entorno de Microsoft con el de Apple (y, presumiblemente, Linux). Los espacios son significativamente más grandes en esas capturas de pantalla en comparación con mis dispositivos.

Mmm, ¿qué deberíamos hacer? ¿Hay alguna manera de que CSS apunte a entornos iOS y macOS para tener un margen de diferencia más grande? — JKVeganAbroad ( discusión ) 15:01, 11 de junio de 2021 (UTC) [ responder ]

Comentario : Lamento sonar negativo, pero todo este asunto (me refiero al "problema del kerning", no a "Wikipedia") parece estar mal concebido. Si en algún sistema, con alguna fuente, algún espaciado no es ideal, esto es un problema para la fuente. Es completamente inapropiado tratar de mejorar esto en un pequeño rincón de Wikipedia. ¿Puede alguien mostrar algunos casos de prueba, con capturas de imágenes, para que podamos ver si este es realmente un problema general para todos los sistemas? (Entiendo que en una situación muy específica, donde estás produciendo una salida fija (es decir, impresa), puede ser apropiado hacer ajustes específicos. Personalmente, se me conoce por mover el espaciado con CSS al hacer un póster con la palabra ピアノ, porque el katakana "realmente" estaba destinado a ser vertical, donde se ve bien, pero cuando se escribe horizontalmente, el espacio entre ア y ノ abre una especie de "río", y mover ア un poquito hacia la derecha brinda un mejor equilibrio. Pero no se me ocurriría sugerir pasar por WP para hacer este tipo de edición global...) Imaginatorium ( discusión ) 18:14, 11 de junio de 2021 (UTC) [ responder ]

Estoy de acuerdo con Imaginatorium. Dudo de la sensatez de una solución CSS para el problema del kerning, ya que evidentemente tiene resultados muy impredecibles en diferentes sistemas y fuentes. Tal vez se pueda implementar una solución en otro lugar (¿alguna búsqueda en Google indica que hay una propiedad CSS para esto? Tal vez se pueda implementar en un nivel superior o simplemente aplicarla localmente un usuario), pero no creo que hacerlo en una plantilla sea una forma adecuada de manejar esto. — Goszei ( discusión ) 20:18, 11 de junio de 2021 (UTC) [ responder ]

No estoy de acuerdo con la idea de "si es un problema con el sistema del cliente, no intentaremos solucionarlo". Si se puede determinar una solución alternativa razonable, entonces no hay realmente ninguna razón para no descubrirla intencionalmente. Además, estamos hablando de sistemas Apple, que no es un tipo de sistema insignificante (y el más universalmente consistente, además). En tercer lugar, yo diría que el inconveniente de un espacio percibido como erróneo es un problema menor que el de los caracteres superpuestos ilegibles (la accesibilidad es más importante). En cuarto lugar, CSS está altamente estandarizado y no es particularmente impredecible en diferentes sistemas en estos días; en lugar de anchos de márgenes CSS inconsistentes, el verdadero problema son las fuentes incontrolables con anchos irregulares.

En cuanto a los casos de prueba con capturas de pantalla, hay casos de prueba sandbox en la parte inferior de las páginas ( nihongo testcases , nihongo krt testcases ). Siéntete libre de agregar más casos de prueba. Si tienes acceso a cualquier dispositivo Apple, verás el problema, pero en cuanto a las capturas de pantalla, ¿dónde las quieres?

Además, volveré a preguntar: ¿hay alguna forma de usar CSS para apuntar a los sistemas de Apple?

— JKVeganAbroad ( discusión ) 12:09 12 jun 2021 (UTC) [ responder ]

Hmm. No se trata solo de no querer solucionar un problema de forma improvisada, sino también de cómo y dónde hacerlo. Básicamente, si todas las fuentes de Apple (¿?) tienen un error que hace que algunas letras en cursiva se bloqueen en un paréntesis de cierre que no sea cursiva, entonces para solucionarlo se necesita una modificación de alto nivel en las hojas de estilo de WP, por lo que esto se soluciona en todas partes, no solo en la plantilla nihongo. (Un lugar extraño para que sea un problema, porque esperaría que las cursivas dentro de paréntesis que no sean cursivas sean Hepburn, y ninguna palabra japonesa normal en Hepburn termina con una letra con un ascendente, ¿no es así?)

Puedes saber (de manera torpe) si tienes un dispositivo Apple en CSS, como en esta pregunta de Stackoverflow. Pero esto tendría que estar en la hoja de estilos, no incrustado en CSS en línea, que creo que es todo lo que una plantilla puede generar.

Mi conocimiento de la tipografía es muy de aficionado; ¿no se supone que los paréntesis alrededor de las cursivas también deben estar en cursiva? La opinión de un experto en tipografía podría ayudar. Sobre los casos de prueba: lo que necesitamos es una muestra del problema que se muestra con la plantilla prekludge, con capturas de imágenes de diferentes sistemas. Si alguien comienza esto, estaré encantado de subir una imagen de lo que veo (algo relacionado con Linux). Imaginatorium ( discusión ) 14:19 12 jun 2021 (UTC) [ responder ]

Tienes razón, no hay un medio apropiado para abordar un sistema específico. La "chapuza" no es la manera.

Después de leer un poco y hacer pruebas ligeras, es posible que exista una mejor solución CSS que minimice el impacto. Podemos cambiar el estilo CSS de la primera o la última letra (en los casos específicos en los que se desee aplicar kerning):

(''pi'')Representaciones: ( pi )

Si el ( pi ) anterior se ve bien en todos los navegadores/sistemas, entonces esta solución alternativa es mejor que la solución alternativa de la brecha de margen. — JKVeganAbroad ( discusión ) 15:45, 12 de junio de 2021 (UTC) [ responder ]

Um, no tan bien, me parece. Por exagerar:

(''pi'')→ ( pi )

Si este es realmente un problema global (según Wikipedia), entonces me parece que la solución global es:

Confirmar que los lectores y editores piensan que es un problema.
determinar si los corchetes que envuelven el texto en cursiva deben estar en posición vertical o también deben estar en cursiva; es mejor hacerlo en una de las páginas de discusión de MOS :
Si los corchetes no deben estar en cursiva, determinar si es posible detectar de manera confiable los detalles del agente de usuario y aplicar algún tipo de CSS apropiado; puede requerir la acción del desarrollador de MediaWiki

Esa lista puede estar incompleta.

—El monje trapense ( discusión ) 16:02 12 jun 2021 (UTC) [ responder ]

Dado que el módulo nihongo utiliza un híbrido de texto en cursiva y no en cursiva, creo que resulta extraño poner el par de paréntesis en cursiva... (y ni siquiera consideremos que solo uno de los paréntesis esté en cursiva, Dios mío). Pero supongo que es aún más extraño que esto no se haya corregido en toda la historia de Wikipedia.

En cuanto a la exageración, a menos que intentes transmitir que ves una gran brecha en 0,08 em, no estoy seguro de entender lo que intentas decir. Quiero decir, para usar una analogía, un poco de medicina es la cura, demasiada medicina es veneno. Entonces deberíamos considerar usar la menor cantidad de medicina que necesitemos, ¿no?

¿Realmente necesitamos, para un conjunto limitado de caracteres en siete escenarios específicos, solicitar una solución global para toda Wikipedia? Para ser claros, no me opongo a esta idea, después de todo es el mejor resultado posible. — JKVeganAbroad ( discusión ) 17:08, 12 de junio de 2021 (UTC) [ responder ]

Estaba tratando de demostrar que en su ejemplo, letter-spacingse aplica a todos los personajes en el...

( algo de pi ) ←(''some pi'')

Pero, escrito de otra manera, cf:

( algunos p i ) ←(''some pi'')

( algo de pi ) ←(''some pi'')

Para mí estos parecen iguales.

Si el problema (caracteres en cursiva que chocan con paréntesis verticales) no se limita a un conjunto limitado de caracteres en siete escenarios específicos , sino que se produce de forma más amplia, de modo que la comunidad (una vez que se entera del problema) cree que la legibilidad se ve afectada, entonces la comunidad en general debería decidir si el problema es lo suficientemente importante como para justificar una solución significativamente suficiente (sí, me gusta la aliteración). Una solución significativamente suficiente probablemente requeriría cambios en MediaWiki:Common.css y, para detectar de forma fiable el agente del usuario, tal vez cambios en la suite de javascript de Mediawiki.

—El monje trapense ( discusión ) 18:12 12 jun 2021 (UTC) [ responder ]

Ahh, no fui lo suficientemente claro con mi ejemplo. Mi ejemplo era una "prueba de concepto" básica y simplificada, utilizando solo 2 caracteres de kerning problemáticos como el primer y el último carácter, y no los previstos para el código final. Si mi ejemplo (pi) se ve mal en .8em, entonces la "solución" propuesta también fallará para todos los demás casos; sin embargo, si el ejemplo (pi) se ve bien, entonces podemos proceder con más pruebas (comparando capturas de pantalla) para ver si es viable. El lapso no debería capturar la palabra romaji completa para esta solución alternativa, o el resultado será el problema que exhibiste.
Sin embargo, supongo que tienes razón, un cambio en Mediawiki beneficiaría a todos. No tengo idea de cómo abordar esto.
Editar: tienes razón, el espaciado entre letras y el margen izquierdo generan una réplica perfecta de cada uno, esta tampoco es la solución. Maldita sea. — JKVeganAbroad ( discusión ) 03:06 13 jun 2021 (UTC) [ responder ]
Yo de nuevo. @Trappist the monk, por el momento, ¿podrías consolidar el parche de error de marcado wiki en el código principal de Nihongo? — JKVeganAbroad ( discusión ) 11:25, 13 de junio de 2021 (UTC) [ responder ]

No sé qué es lo que estás preguntando. ¿Qué parche de errores de marcado wiki ? ¿Cómo consolidar o con qué?

—El monje trapense ( discusión ) 11:35 13 jun 2021 (UTC) [ responder ]

Para ser más específico, este parche que hiciste para el sandbox corrige el error en el que el marcado wiki se analiza como caracteres válidos que requieren interletraje. Si pudieras consolidar esta variación de código con el módulo nihongo, detendrías los errores que Goszei notó al comienzo de esta discusión. — JKVeganAbroad ( discusión ) 12:56, 13 de junio de 2021 (UTC) [ responder ]

hecho

—El monje trapense ( discusión ) 13:33 13 jun 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 18 de junio de 2021 — Compromiso: Reducción de casos marginales

1029697775 Propongo este compromiso . Como se mencionó en las discusiones anteriores, tal vez podríamos poner en cursiva el paréntesis para resolver el problema. No estoy de acuerdo con la combinación de corchetes de apertura sin cursiva con corchetes de cierre en cursiva (o viceversa). Sin embargo, en mi propuesta, elimino el caso marginal donde sucede ENGLISH (ROMAJI), al poner en cursiva el paréntesis en este caso. Esto reduce los casos marginales a los casos 70 y 73 de los casos de prueba nihongo y 44 , 47 y 48 de nihongo krt . Eso son 5 casos en total.

Además, hice pruebas graduales y estoy conforme con reducir la brecha en estos 5 casos marginales a 0,09em, según la propuesta.

¿Qué opinas?

JKVeganAbroad ( discusión ) 02:17 18 jun 2021 (UTC) [ responder ]

Anteriormente en esta serie de discusiones escribí:

Si este es realmente un problema global (según Wikipedia), entonces me parece que la solución global es:
Confirmar que los lectores y editores piensan que es un problema.
determinar si los corchetes que envuelven el texto en cursiva deben estar en posición vertical o también deben estar en cursiva; es mejor hacerlo en una de las páginas de discusión de MOS :
Si los corchetes no deben estar en cursiva, determinar si es posible detectar de manera confiable los detalles del agente de usuario y aplicar algún tipo de CSS apropiado; puede requerir la acción del desarrollador de MediaWiki
Esa lista puede estar incompleta.

¿Se han abordado estas cuestiones? ¿Dónde?

Por curiosidad, estas búsquedas:

insource:/[^']''\([^\)]+\)''/87.801

insource:/\(''[^'][^\)]+[^']''\)/312.111 (tiempo de espera agotado)

Si estas búsquedas tienen alguna validez, los resultados sugieren que los editores prefieren que el texto en cursiva esté entre paréntesis verticales. Si ese es el caso, no se debería aceptar esta solicitud de edición.

—El monje trapense ( discusión ) 13:06 18 jun 2021 (UTC) [ responder ]

En cuanto a los resultados de búsqueda de expresiones regulares, en particular dado que el segundo se agota, estoy de acuerdo en que no se debe respetar esta solicitud de edición. No creo que sea necesario determinar esto en una de las páginas del Manual de estilo, ya que los resultados de búsqueda que se agotan son bastante concluyentes (democráticamente) de que no es preferible poner los corchetes en cursiva. Por lo tanto, mi opinión sobre el punto n.° 2 es que esto se ha determinado y los corchetes que envuelven el texto en cursiva deben estar en posición vertical.

En cuanto al punto n°1, esto requiere una encuesta de algún tipo, en algún tipo de lugar.

En cuanto al punto 3, eso solo se puede llevar a cabo después de recibir la opinión de la comunidad sobre el punto 1. Si la comunidad no ve un problema, entonces es inútil investigar una solución.

Supongo que voto por que el punto n.° 1 debería ser una prioridad. Sin embargo, mientras tanto, la sugerencia de eliminar la implementación actual de compensación de kerning no es una idea que yo respalde. En mi opinión, la legibilidad es mayor que la detección de espacios erróneos. — JKVeganAbroad ( discusión ) 13:54, 19 de junio de 2021 (UTC) [ responder ]

Solicitud de edición protegida por plantilla el 21 de junio de 2021: Compromiso: reducción del ancho de la brecha de compensación

Propongo otro compromiso . Me doy cuenta de que se trata de un debate en curso y de que actualizar constantemente el módulo mientras el código es polémico no es una situación ideal, pero tal vez cambiar la apariencia de la brecha de compensación de kerning también cambie la percepción del debate.

Lamentablemente, sugerí un cambio de .1em a .2em sin realizar las pruebas adecuadas. En ese momento, el espacio más grande parecía más cómodo, pero ahora creo que mi percepción fue errónea. Desde entonces, he implementado una importante plantilla lang/transl/nihongo en la página de gramática japonesa para que esté en línea con el marcado de lenguaje HTML accesible, y esa página usa la plantilla nihongo ampliamente. Me queda claro que un espacio de .2em es excesivo en una variedad de letras en cursiva. Ajustar el CSS en el kit de desarrollo de mi navegador demostró que .09em es aceptable en mi sistema.

Los casos de prueba nihongo y los casos de prueba nihongo krt indican que el código propuesto no causa fallas detectables, por lo que es posible fusionarlos.

Si es posible, me gustaría ver este código fusionado tentativamente mientras continuamos la discusión sobre las implicaciones más amplias de los problemas de kerning entre los diferentes sistemas en Wikipedia.

— JKVeganAbroad ( discusión ) 14:19 21 jun 2021 (UTC) [ responder ]

Comentario : Brevemente, repito mi comentario anterior. Creo que este proyecto está mal concebido. Si las reglas de kerning para algunas fuentes en algunos sistemas no son del todo satisfactorias, el proyecto tiene que ser mejorar las reglas de kerning. Jugar con un pequeño rincón de WP para solucionar esto no es una buena estrategia, e inevitablemente terminará perdiendo el tiempo de alguien más, así que me opongo a toda la idea, incluso si se revisa, se compromete o lo que sea. Imaginatorium ( discusión ) 15:30, 21 de junio de 2021 (UTC) [ responder ]

…y, inevitablemente, terminará desperdiciando el tiempo de otra persona… — No entiendo este argumento. Antes de tomar la iniciativa de resolver este problema a través de nihongo module, usaba  en cada ocurrencia en la sintaxis de nihongo romaji. Esto era muy ineficiente: laborioso y agregaba un molesto carácter invisible si la gente copiaba y pegaba el texto. Pero resolvió el problema del kerning. Después de que se implementó el cambio de código en nihongo, también fue laborioso eliminar  de los artículos; sin embargo, al menos el problema se resolvió para cada código de nihongo a partir de entonces.

Si en el futuro este problema tiene una solución global, sólo necesitaremos modificar el código de una página: la nihongo module. Eso no entra en la definición de pérdida de tiempo, en mi opinión.

Sin embargo, el riesgo de no tener una solución local es que otros usuarios podrían usar  caracteres o soluciones manuales equivalentes caso por caso, de la misma manera que yo lo hice. No podemos esperar que se den cuenta de que necesitan cambiar el módulo nihongo por sí mismos. Además, es claramente una pérdida de tiempo mucho mayor si se implementa una solución global y tenemos que buscar las  modificaciones manuales que la gente ha usado en el módulo nihongo para evitar problemas de kerning.

En resumen, no entiendo cómo toda esta idea acabará inevitablemente haciendo perder el tiempo a alguien más. Creo que editar solo el módulo nihongo ahorra tiempo.

De todas formas, puedo entender los otros puntos que planteaste. — JKVeganAbroad ( discusión ) 16:16 21 jun 2021 (UTC) [ responder ]

@JKVeganAbroad : Respuesta tardía a tu pregunta razonable. Por supuesto, no puedo decir exactamente cuánto tiempo se perderá, pero supongamos que tu idea se lleva a cabo... Entonces habrá cientos de plantillas como 'Nihongo' con ediciones chapuceras para ajustar el kerning en varias combinaciones de letras en cursiva. (Me equivoqué, por cierto, al afirmar que el japonés romanizado no termina con letras con ascendentes, porque la 'i' minúscula tiene el punto, que está en la posición de un ascendente). De todos modos, creo que tu técnica original de poner caracteres de espacio fino en varios fragmentos de texto de WP es la forma incorrecta de abordar el problema, y poner ajustes CSS en plantillas también es la forma incorrecta. Sin lugar a dudas, es probable que esta forma incorrecta pierda menos tiempo que la forma incorrecta original, pero eso no la convierte en la forma correcta. Imaginatorium ( discusión ) 11:34, 10 de julio de 2021 (UTC) [ responder ]

No se ha terminado La discusión que sigue (en #Consensus?) hace que esta solicitud sea irrelevante. Rechazo procesal. *Pppery* _{ha comenzado...} 19:20, 16 de julio de 2021 (UTC) [ responder ]

¿Consenso?

¿En qué punto se encuentra el consenso en este momento sobre el cambio en vivo? Creo que debería revertirse por ahora, a la espera de un debate más amplio sobre el problema y de si se puede encontrar una solución que sea algo consistente. Haciendo ping a los comentaristas anteriores en la discusión. — Goszei ( discusión ) 01:48, 18 de junio de 2021 (UTC) [ responder ]

No estoy seguro de qué hacer con esta discusión, ya que parece haberse estancado debido a un débil consenso en contra del cambio implementado (débil porque solo hubo 4 editores involucrados). Hice varios intentos de ampliar la discusión en WT:JAPAN y VPT sin éxito. No estoy seguro de que el camino procedimental sea este (¿quizás un cambio de postura por parte de Trappist y luego la apertura de un hilo más amplio en un lugar más central? ¿Una RfC? Realmente no estoy seguro). Creo que todas las partes están interesadas en ver más participación y una discusión más amplia del problema.

He contactado con los otros dos editores involucrados para discutir el camino procesal a seguir. — Goszei ( discusión ) 23:21, 4 de julio de 2021 (UTC) [ responder ]

Apoyo la propuesta de una convocatoria de propuestas, porque básicamente necesitamos más opiniones. — JKVeganAbroad ( discusión ) 01:09, 5 de julio de 2021 (UTC) [ responder ]

He revertido los cambios en cuestión, debido al débil consenso en contra de ellos en este momento. Sin perjuicio de una futura convocatoria de propuestas, redactada de manera neutral y exhaustiva. — Goszei ( discusión ) 05:20 10 jul 2021 (UTC) [ responder ]

Yo también estoy en contra de resolver los problemas de kerning en la representación de fuentes aquí en este módulo de Scribunto. Francamente, se trata de un truco para resolver el problema que debería solucionarse en el navegador o en las propias fuentes. Si estamos proponiendo una solución alternativa para estos problemas, estos deberían gestionarse en un único lugar centralizado (por ejemplo, un módulo de kerning) que se pueda actualizar a medida que cambie la tecnología para solucionar el problema donde exista (es decir, el truco se puede ajustar a medida que la fuente del problema se resuelve con el tiempo). Además, creo que esto debería utilizar CSS y no producir ningún carácter Unicode como espacios finos o finos que podrían detectarse al copiar texto (ya que el kerning no es realmente una parte del texto en sí, sino cómo se representa). — Uzume ( discusión ) 06:11, 12 de julio de 2021 (UTC) [ responder ]

Estoy decepcionado con este resultado. Especialmente cuando Goszei propuso un RfC y luego simplemente decidió "lo que sea, lo cambiaré yo mismo sin hacer el RfC". Tampoco estoy satisfecho con la forma en que se revirtió, porque algunas de las revisiones más nuevas eliminaron terminología del código ("un experimento para implementar...") pero Goszei la reintrodujo. En última instancia, no estoy dispuesto a buscar una corrección global, ya que no tengo las habilidades o el conocimiento necesarios, pero espero que alguien lo haga. Después de todo, este problema de kerning está afectando a todos los dispositivos iPhone, iPad y macOS del planeta, y esa no es una pequeña minoría digna de desconsideración. — JKVeganAbroad ( discusión ) 03:22, 18 de julio de 2021 (UTC) [ responder ]

Arreglar la página vinculada "Hepburn" en la plantilla bengalí.

La palabra "Hepburn" en la plantilla nihongo redirecciona a la página wiki "Romanización de Hepburn". Pero la palabra "হেপবার্ন" (hepburn) en la plantilla bengalí no redirecciona a la página wiki en bengalí real de Hepburn "হেপবার্ন রোমান লিপি", como la plantilla en; en lugar de eso, promueve la creación de una página completa porque no existe.

Ahora, puedo crear una página con este nombre "হেপবার্ন" y redirigirla a la página real; pero creo que sería mejor corregirlo en el núcleo. En todas las páginas wiki de Bangla que usaron esta plantilla "nihongo", la palabra Hepburn (হেপবার্ন) está en ROJO, aunque existe. Y probablemente esta ocurrencia se da desde el comienzo de esta plantilla. Sin embargo, no se ha corregido.

¿Alguien a cargo de esta plantilla o con autoridad, por favor podría solucionar este problema? La palabra "হেপবার্ন" debería vincularse a la página wiki llamada "হেপবার্ন রোমান লিপি".

Gracias por leer. লাবিব আহমদ (discusión) 06:07, 11 de junio de 2021 (UTC) [ respuesta ]

Se trata de bn:টেমপ্লেট:Nihongo? Esa plantilla no está protegida, por lo que deberías poder modificarla [[Hepburn romanization|হেপবার্ন]]tú [[হেপবার্ন রোমান লিপি|হেপবার্ন]]mismo.

—El monje trapense ( discusión ) 11:54 11 jun 2021 (UTC) [ responder ]

Uso del parámetro 'lead=yes'

No parece haber ninguna guía oficial sobre dónde y cuándo utilizar el parámetro lead=yes, y su uso es irregular y escaso. Por ejemplo, compare Mitsubishi (que utiliza lead=yes) y Sony (que no utiliza lead=yes). También se sugiere en esta página de discusión que el parámetro no se debe utilizar en artículos biográficos, es decir, en los que el nombre en japonés es el comienzo.

¿Es necesario este parámetro en primer lugar? La sugerencia es que el encabezamiento debe identificar a los lectores desconocidos en qué idioma están leyendo. ¿Es esto realmente necesario cuando la mayoría de los artículos sobre empresas, personas, etc. japonesas dicen que el tema del encabezamiento es el japonés?
Si el parámetro se considera necesario, ¿se deben cambiar los cables que no lo utilizan para utilizar el parámetro cuando sea apropiado, por ejemplo en Sony o Yamaha ?
Si se considera necesario el parámetro, ¿debería utilizarse en artículos biográficos? ¿Qué sucede con todos los demás artículos en los que el nombre en inglés es una romanización directa del japonés de Hepburn? (Ejemplo: Yorushika ).

— Jthistle38 ( discusión ) 16:08 7 ene 2022 (UTC) [ responder ]

¿Nadie tiene una opinión al respecto? ¿O esta página de discusión no está supervisada en absoluto? — JThistle38 ( discusión ) 19:10 6 feb 2022 (UTC) [ responder ]

Esta página está monitoreada; hay 85 editores que la miran (no se sabe si los 85 editores siguen activos). Sospecho que la naturaleza de esta pregunta tiene más que ver con el estilo que con la plantilla en sí. Tal vez sea mejor hacer tu pregunta en MOS:JAPAN (278 observadores) con aviso a WT:JAPAN (464 observadores); se aplican las mismas advertencias.

|lead=yesSe agregó como resultado de esta discusión entre marzo y octubre de 2011.{{nihongo}}

—El monje trapense ( discusión ) 19:35 6 feb 2022 (UTC) [ responder ]

Vale, puede que lo mencione allí. Muchas gracias. — JThistle38 ( discusión ) 21:53 6 feb 2022 (UTC) [ responder ]

¿Traducción literal entre paréntesis?

Esta sería una opción útil, la configuración extra2 fuera de los corchetes solo parece apropiada para el caso (¿de nicho?) donde se usa en una lista de deflist.

Si se utiliza esta plantilla al comienzo de la introducción de un artículo, no se lee bien si la traducción literal está fuera de los corchetes; las únicas opciones son poner la traducción literal en su propio segundo conjunto de corchetes (como en el artículo de Sokoban ) o no utilizar la plantilla. -- Lord Belbury ( discusión ) 09:22 6 jun 2022 (UTC) [ responder ]

¿Qué hay de malo en utilizar únicamente el parámetro 'extra' normal?

{{nihongo|'''''Sokoban'''''|倉庫番|''Sōko-ban''|{{lit|warehouse keeper}}}}

donación

Sokoban (倉庫番, Sōko-ban , literalmente ' encargado de almacén ' )

— Jthistle38 ( discusión ) 09:39 6 jun 2022 (UTC) [ responder ]

¡Ah! Tienes razón, es exactamente lo que necesitaba. Debo haberlo pasado por alto porque los ejemplos de la documentación no lo incluyen. Lo agregaré allí. Gracias. -- Lord Belbury ( discusión ) 09:47 6 jun 2022 (UTC) [ responder ]

¿Las romanizaciones de Hepburn no siguen las reglas normales?

Me parece que los ejemplos de romanizaciones de Hepburn no siguen las convenciones utilizadas en la mayor parte de la Wikipedia en inglés.

"Tokyo Tower" parece ser un nombre propio, ya que está escrito en inglés con ambas palabras en mayúscula. ¿Por qué Hepburn dice Tōkyō tawā , como si el término no fuera un nombre propio, y no Tōkyō Tawā ?

¿Por qué Sōko-ban se escribe con guion? En el artículo de Wikcionario en inglés de la palabra se escribe Sōkoban , que sigue las reglas de romanización de ALA-LC para espaciar la romanización del japonés. Tempjrds ( discusión ) 23:53 18 sep 2022 (UTC) [ responder ]

Si hay un fallo con Tōkyō tawā y Sōko-ban , no es culpa de la plantilla sino, más bien, un fallo en las elecciones hechas por los editores que usan la plantilla.

No sé nada sobre Hepburn ni sobre las romanizaciones de la ALA-LC (y no quiero saberlo), pero me pregunto por qué estás usando las reglas de la ALA-LC como evidencia de que alguien no siguió las reglas de Hepburn. Eso simplemente no tiene sentido para mí.

—El monje trapense ( discusión ) 00:25 19 sep 2022 (UTC) [ responder ]

Trappist: Estas son las palabras de ejemplo que se utilizan en los documentos de la plantilla. @Tempjrds: si crees que los documentos se pueden mejorar en este sentido, ¡hazlo! Vale la pena señalar que esta plantilla no exige nada sobre cómo se romanizan las palabras; simplemente proporciona una forma de diseñar fácilmente el texto japonés con una traducción y romanización en inglés correspondiente. No le importa qué método de romanización se utilice. Creo que eso es tarea de WikiProject Japón. — Jumbo T ( discusión ) 17:54, 20 de septiembre de 2022 (UTC) [ responder ]

bifurcación

Module:Nihongo fue bifurcado para admitir una nueva plantilla . La bifurcación generalmente se considera algo malo, por lo que he modificado y actualizado Module:Nihongo para que pueda admitir otras plantillas para textos que no estén en japonés. Module:Nihongo probablemente debería cambiar de nombre para reflejar su capacidad de ser neutral en cuanto al idioma, aunque no he podido pensar en un buen nombre; si conoce un buen nombre para el módulo generalizado, hágamelo saber. Agregar un conjunto de plantillas similares para otro idioma simplemente requiere la adición de un conjunto de tablas de configuración (ubicadas en la parte superior del código del módulo).{{hanyu}}{{hanyu}}{{nihongo}}

Palabras famosas: esta actualización no debería haber dañado ninguna plantilla {{nihongo}}, , o existente . Si lo hizo, por favor, háganmelo saber.{{nihongo3}}{{nihongo krt}}{{nihongo foot}}

—El monje trapense ( discusión ) 13:15 8 oct 2022 (UTC) [ responder ]

Abreviatura

Hola. ¿Cuál es la sintaxis de uso recomendada para incluir una abreviatura? Por ejemplo, JEITA se vería preferiblemente de la siguiente manera:

Asociación de Industrias de Tecnología de la Información y Electrónica de Japón (JEITA; japonés: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai)

En cambio, produce:

Asociación de Industrias de Tecnología de la Información y Electrónica de Japón (japonés: 社団法人電子情報技術産業協会, Hepburn: Shadan-hōjin Denshi Jōhō Gijutsu Sangyō Kyōkai, JEITA)

Gracias. fgnievinski ( discusión ) 02:46 2 jun 2023 (UTC) [ responder ]

Excluyendo la etiqueta en inglés

Quiero usar esta plantilla sin insertar la etiqueta en inglés. Cada vez que dejo esa etiqueta vacía, la plantilla incluirá automáticamente la versión en inglés del japonés. Solo necesito Kanji/Kana junto con la romanización. ¿Alguna ayuda con este problema? ZanzibarSailor (discusión) 23:49 14 sep 2023 (UTC) [ responder ]

No sé qué quieres decir con etiqueta en inglés . Puedes omitir la traducción al inglés si eso es lo que estás buscando:

{{Nihongo||東京タワー|Tōkyō tawā}}→ Tōkyō tawā (東京タワー)

o puedes usar y para hacer una representación personalizada:{{transliteration}}{{lang}}

{{transliteration|ja|Tōkyō tawā}} ({{lang|ja|東京タワー}})→ Tōkyō tawā (東京タワー)

—El monje trapense ( discusión ) 00:25 15 sep 2023 (UTC) [ responder ]

¿Existe algún soporte para los corchetes?

¿ Existe algún soporte para el uso de corchetes dentro de los paréntesis? — AjaxSmack 14:09, 11 de marzo de 2024 (UTC) [ responder ]

¿Qué apoyo cree que se requiere? Las entradas de la plantilla pueden incluir corchetes. Siempre proporcione un ejemplo real de lo que cree que no funciona.

—El monje trapense ( discusión ) 14:26 11 mar 2024 (UTC) [ responder ]

Solo el uso estándar (si no universal) de corchetes para paréntesis anidados. Ha surgido en ediciones que he hecho en el pasado, pero no recuerdo dónde. Por lo general, simplemente evito esta plantilla cuando estoy escribiendo y reformulo la oración cuando estoy editando. Sin embargo, aquí hay un caso hipotético: "Las patas arqueadas de la mesa (a pesar del nombre japonés sabi-wabi (寂び侘び) ) no son ni tenues ni austeras". Si bien en este caso reemplazaría los paréntesis (corchetes) con comas, en otros casos no funcionará, como en "La flauta de 45 cm (1,5- shaku (尺) ) es una parte integral de la orquesta". — AjaxSmack 00:03, 12 de marzo de 2024 (UTC) [ responder ]

En primer lugar, si vas a utilizar esta plantilla, úsala correctamente. Arriba escribiste:

{{Nihongo|''sabi-wabi''|寂び侘び}}→ sabi-wabi ( hablando en serio )
{{Nihongo|''shaku''|尺}}→ shaku (尺)

Deberías haber escrito:

{{Nihongo||寂び侘び|sabi-wabi}}→ sabi-wabi ( hablando en serio )
{{Nihongo||尺|shaku}}→ shaku (尺)

Sí, las representaciones parecen iguales, pero en realidad no lo son; cf:

''sabi-wabi'' (寂び侘び)
sabi-wabi (寂び侘び)

Estoy bastante seguro de que podríamos agregar un parámetro |use-square-brackets=yes(caso predeterminado no) o algo similar, que haría que Módulo:Nihongo represente corchetes en lugar de paréntesis.

—El monje trapense ( discusión ) 00:55 12 mar 2024 (UTC) [ responder ]

Gracias por el consejo de uso. Por esa ambigüedad, suelo evitar esta plantilla. — AjaxSmack 03:32, 12 de marzo de 2024 (UTC) [ responder ]

Soporte parakanji y cana?

¿Hay alguna forma de hacer que esta plantilla muestre kanji y kana en campos separados? Muchas plantas en japonés usan tanto katakana como kanji dependiendo del contexto (por ejemplo, "Llamada seri (セリ;芹) en japonés, es..." de Oenanthe javanica .) Cf. {{zh}} donde puedes conseguir cosas como台灣國;台湾国; Tâi-oân-kok ; ㄉㄞˊㄨㄢˊㄍㆦㆻ . - AjaxSmack 17:54, 22 de agosto de 2024 (UTC) [ respuesta ]

Viene el editor que, en otra discusión en esta página, escribió: Tal arcanismo es la razón por la que normalmente evito esta plantilla. ¿Pedir aún más arcanismo ?

Puedo imaginar nuevos parámetros. Si alguno de ellos está presente, el valor asignado al segundo parámetro posicional se ignoraría; el segundo parámetro posicional seguiría siendo necesario para que el tercero funcione. Aparentemente, hay tres sistemas de escritura japoneses. Si tenemos en cuenta esto, ¿vale la pena admitirlos todos?

katakana– ; |kana=Escritura ISO 15924 Kana

kanji – |kanji=; Guión ISO 15924 Hani

hiragana – |hira=; secuencia de comandos ISO 15924 Hira

Si hacemos esto, ¿cómo debería verse la representación cuando se utilizan más de uno de estos textos específicos del script en una plantilla?{{nihongo}}

—El monje trapense ( discusión ) 20:07 22 ago 2024 (UTC) [ responder ]

Gracias por dedicarnos un poco de tu tiempo. "Llega el editor... ¿Pidiendo aún más "arcanidad"?" Touché. El tipo de arcanidad al que me refería es el que {{nihongo}}funciona de manera bastante diferente a otras plantillas de lenguaje similares. Agregar características opcionales, aunque técnicamente es arcano, no requiere que todos los usuarios las conozcan.

"[E]l valor asignado al segundo parámetro posicional sería ignorado – el segundo parámetro posicional aún sería requerido..." Así: {{nihongo|seri||kana=セリ|kanji=芹}}→ seri (katakana:セリ; kanji:芹) , ¿o quieres decir que realmente necesitaría haber texto en el segundo parámetro posicional?

“¿Vale la pena apoyarlos a todos?” Bueno, ya se apoyan, es cuestión de poder ofrecerlos por separado para poder etiquetarlos.

"Si hacemos esto, ¿cómo debería verse la representación..."? No estoy seguro de lo que quieres decir. ¿Quieres decir que deberían estar etiquetadas o deberían estar en un orden determinado o...? Soy un intruso del mundo {{zh}}donde las etiquetas vinculadas, las etiquetas no vinculadas, la ausencia de etiquetas y la reordenación de parámetros son posibles. — AjaxSmack 00:08, 15 de septiembre de 2024 (UTC) [ responder ]

{{lang}}fue creado el 25 de enero de 2005; fue creado el 9 de octubre de 2005; fue creado (como ?) el 18 de septiembre de 2009; todos por diferentes editores, por lo que no debería sorprenderle que todos funcionen de manera diferente.{{nihongo}}{{lang-zh}}{{zh}}

Sí, así en su mayoría.

{{nihongo|seri||kana=セリ|5=kanji=芹|lead=yes}}

Podría mostrar algo como esto:

seri ( katakana :セリ; kanji :芹)

sin|lead=

{{nihongo|seri||kana=セリ|5=kanji=芹}}

Podría mostrar algo como esto:

seria (セリ;芹)

No es lo que quise decir. Lo que pregunto es: ¿deberíamos admitir los tres sistemas de escritura con tres parámetros separados: , , ?|kata=<katakana text>|kanji=<kanji text>|hira=<hiragana text>

El etiquetado está vinculado a |lead=lo anterior, por lo que es importante que, sea cual sea el orden que elijamos, sea coherente, con etiquetado o sin él.

—El monje trapense ( discusión ) 14:43 15 sep 2024 (UTC) [ responder ]

Así que hackeé el módulo:Nihongo/sandbox para usarlo |kana=y |kanji=:

{{nihongo/sandbox|seri|some stuff that gets ignored|kana=セリ|kanji=芹|lead=yes}}– ignora todo lo que está en{{{2}}}
seri ( japonés : algunas cosas que se ignoran )
{{nihongo/sandbox|seri||kana=セリ|kanji=芹|lead=yes}}– ignora el vacío{{{2}}}
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )
{{nihongo/sandbox|seri||kana=セリ|kanji=芹}}– Kana y Kanji sin plomo
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )
{{nihongo/sandbox|seri||kana=セリ|lead=yes}}– cana
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )
{{nihongo/sandbox|seri||kana=セリ}}– Kana sin plomo
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )
{{nihongo/sandbox|seri||kanji=芹|lead=yes}}– kanji
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )
{{nihongo/sandbox|seri||kanji=芹}}– kanji sin plomo
error: {{nihongo}}: Se requiere texto en japonés o romaji ( ayuda )

Necesito reescribir lo que he hecho para poder incorporarlo.|hira=

—El monje trapense ( discusión ) 22:31 15 sep 2024 (UTC) [ responder ]