Colones en IU internacionalizada

Al usar gettext o un marco similar, ¿deberían las cadenas de traducción incluir ':'(como "Label:") para generar etiquetas para la interfaz de usuario o debo agregar el ':'código de la interfaz de usuario?

El colon puede considerarse como un símbolo de puntuación. Es una convención que forma parte del texto, al igual que un punto o un signo de interrogación.

No dejaríamos de lado el signo de interrogación de "¿Está seguro de que desea salir?" y luego escriba código para agregar los atributos de la pregunta de manera dependiente del idioma a la cadena traducida. Hacerlo significa que el código de la IU asume innecesariamente las responsabilidades de saber puntuar las oraciones en varios idiomas: una responsabilidad que se puede manejar en la sustitución del mensaje.

Hay una posibilidad intermedia. Es probable que, al igual que todas las etiquetas tengan la función de dos puntos en inglés, en otros idiomas las etiquetas también tengan algún elemento léxico en común. Ese elemento, si está presente, es probablemente algún tipo de prefijo o sufijo, o ambos.

Puede representar las etiquetas sin el adorno y luego tener una cadena traducible adicional que proporcione un esquema para agregar el adorno de la etiqueta. Como ejemplo, suponga que el sprintfformato de estilo C está disponible en la aplicación UI. La versión en inglés de la cadena de formato de generación de etiquetas sería "%s:", y también podría ser la predeterminada, ya que funciona en algunos otros idiomas. Los traductores de la interfaz de usuario pueden reemplazar esto "%s:"con lo que mejor les parezca. Una de las posibilidades es que pueden reemplazarlo con solo "%s"(no hacer nada) y luego especificar la representación completa y adornada de cada etiqueta en la tabla de cadenas traducidas. Entonces, este enfoque incluso maneja algunas posibilidades extrañas donde el marcador léxico que denota una etiqueta tiene que insertarse en el medio.

Este enfoque no parece valer la pena, si todo lo que logra es una ligera compresión en la representación de las cadenas de etiquetas: la eliminación de un carácter de dos puntos. Si tiene que escribir 100 caracteres de código adicional para esto, debe eliminar los dos puntos de 100 etiquetas solo para alcanzar el punto de equilibrio: y eso ni siquiera tiene en cuenta la justificación del tiempo empleado.

Tiene que haber algún beneficio para esto: a saber, que la aplicación usa las cadenas para fines que no sean solo generar etiquetas, como generar oraciones que se refieren a los campos de la interfaz de usuario por nombre. Digamos que un cuadro de diálogo tiene una etiqueta de "ID de usuario:" para ingresar texto. Si tiene una lógica genérica que produce el mensaje "Ha ingresado una ID de usuario no válida". combinando un texto repetitivo de oraciones con el nombre de un elemento de la interfaz de usuario, es necesario tener la cadena "ID de usuario" sin adornos y pasarla a través de una función de creación de etiquetas para generar "ID de usuario:".

Para muchos idiomas, no existe una traducción individual de palabras y frases en inglés, sino múltiples traducciones que son sensibles al contexto.

Para facilitar la vida de los traductores, debe proporcionar el mayor contexto posible para las cadenas. Eso incluye dos puntos en las etiquetas y la información contextual donde se usan esas etiquetas.

Como reglas básicas, en una interfaz de usuario internacionalizada debe

• no modifique las cadenas traducidas, excepto para completar los parámetros con sus valores reales. Por lo tanto, no agregue los dos puntos después del hecho.
• no cortar cadenas en partes alrededor de los parámetros. Especialmente si hay que completar varios parámetros, puede estar seguro de que habrá al menos un idioma en el que sería más natural tener los parámetros al revés.
• tenga mucho cuidado con las formas singulares / plurales. No hay un patrón común sobre cómo crear plurales a partir de singulares, o incluso cuántas formas plurales hay.

Finalmente decidí usar cadenas enteras (cadenas con dos puntos en este caso) en mis archivos i18n.

La razón de esto es que en francés debería haber un espacio antes de los dos puntos. Entonces, la mejor manera de codificar francés es poner dos puntos (con espacios antes) en cadenas de traducción.

No, no traducimos al francés. Pero este es un ejemplo de una regla general de comportamiento: poner dos puntos en las cadenas de traducción, no en el código de la interfaz de usuario.

El enfoque óptimo es incrustar los caracteres en la cadena para cada ubicación, ya que eso generalmente garantiza que el contexto sea correcto, suponiendo que haya investigado lo que su público objetivo espera.

Cada país generalmente proporciona una guía de estilo, que dicta todos los lugares "correctos" para la puntuación. Entonces, cuando comencé a calcular cómo manejaría las citas de diferentes idiomas para algunas herramientas de diseño web, primero miré esas guías de estilo.

Sin embargo, si bien las publicaciones escritas tienden a seguir las guías de estilo, ¡el mundo en línea es bastante diferente! Por lo general, una gran cantidad de sitios europeos y sudamericanos que no están en inglés utilizan citas de estilo estadounidense, a diferencia de los guillemets («») de sus guías de estilo. Solo muestra cuánto el dominio de los EE. UU. De la primera web impregna el uso del idioma en línea en todo el mundo.

The MIT Foreign Language News and Newspapers: Home tiene enlaces a cientos de sitios en línea. Mirar esto me ayudó a encontrar el mejor enfoque para mi dilema, que era proporcionar la facilidad para que el propietario del sitio seleccionara uno de los 19 conjuntos más populares de combinaciones de citas incrustadas, apropiadas para su público objetivo.

Chrome intenta usar automáticamente la guía de estilo de un país, pero afortunadamente puede anularse especificando una configuración regional en el atributo lang de la etiqueta q . Esto resalta el problema con los enfoques automáticos que no tienen en cuenta el mundo real, sino que dependen de la teoría para sus implementaciones.

Para el OP, investigue esos sitios de periódicos en línea para ver qué se usan realmente en varios países, para que pueda ver qué enfoque dará los resultados más consistentes.

Mientras que algunos idiomas han usado tradicionalmente un carácter diferente para el colon en inglés, el uso en línea puede apuntar a audiencias acostumbradas a ese colon. Además, las diferentes configuraciones regionales pueden tener un uso diferente, lo que requiere especificar cadenas de idioma para cada configuración regional completa, en lugar de solo por idioma.

Cuando estaba haciendo mi propia internacionalización hace unos años, funcionó algo como esto:

• Los mensajes en el código fuente fueron escritos en inglés

• Los mensajes se tradujeron en tiempo de ejecución mediante la aplicación de una traducción (que apareció en la fuente como translate ("string") o más habitualmente / "string"). Se esperaba que hubiera un diccionario pre-construido de mensajes y traducciones.

• Al traducir un mensaje, se recortó el espacio en blanco en cada extremo y se eliminó la puntuación final, al igual que cualquier capitalización. Después de traducir lo que quedaba, se volvieron a colocar.

• Para proporcionar más contexto, a veces agregué un comentario a la cadena, que era parte del proceso de traducción para ayudar a encontrar la mejor coincidencia, pero el comentario fue descartado.

Entonces, con un mensaje como "Disco:", la cadena "disco" se tradujo a, por ejemplo, "disquette", y luego se volvió a componer como "Disquette:". Esto redujo el número de mensajes muy similares.

Solo hice esto para un pequeño número de idiomas de Europa occidental; probablemente habría problemas con los más exóticos. Sin embargo, estaba usando un lenguaje de tipo secuencia de comandos para esto, por lo que podría usarse algún procesamiento de cadena para cualquier problema que surgiera: cuando necesitaba traducir "G" (abreviatura de Verde), apareció en la fuente a la izquierda (/ "Verde" ), traducido a algo como "vert" y reducido a "V".

Sin embargo, no estoy familiarizado con los marcos actuales y cómo podrían funcionar; ¿No proporcionan pautas para tratar este tipo de problemas?

Puede depender del sistema de localización que use, pero teniendo otras cosas iguales, personalmente evitaría agregar cualquier puntuación (a menos que, dentro de una frase, por supuesto, donde su uso esté dictado por la gramática), porque siento que son parte de la presentación , como tamaño de fuente, etc., y no realmente el contenido . Así que estamos mezclando diferentes cosas con este enfoque.

Después de todo, las mismas palabras y frases pueden ser necesarias tanto con puntuación como sin ella. P.ej. puede tener un "Enter subject:"título junto a un cuadro de texto, pero también "Enter subject"como título de una ventana.

¿Tiene sentido que ambos se traduzcan por separado?

Cuando decida que los dos puntos realmente se ven mal y redundantes en la interfaz de usuario, tendrá que volver a traducir todas las versiones de idiomas. Lo cual es un poco tonto.

PD. Las "reglas básicas" dadas por @bartc son válidas de cualquier manera, ya sea que incluya o no signos de puntuación en las cadenas traducidas.

PPS @paulkayuk también plantea un buen punto (en su comentario): que los detalles de la cultura también deben tenerse en cuenta. Si tiene cosas como signos de interrogación reflejados en español, inclúyalos en su traducción, por supuesto. Mi respuesta supone una puntuación uniforme y agnóstica del lenguaje, porque esa parece ser la parte discutible.

Un archivo de idioma de aplicación no es solo una traducción ficticia de palabras. Es un proceso en el que traduce las palabras y su "presentación" de puntuación en el contexto significativo correcto .

Hello?en español es ¿Hola?en árabe es مرحبا؟. Como puede ver, no puede simplemente almacenar un Helloo Holao مرحباy luego en la interfaz de usuario simplemente hacer un the_hello_text + "?". No producirá la salida correcta. Es obvio que la puntuación debe tenerse cuidado en el archivo de idioma. Eso significa que no es asunto de la GUI "agregar" un signo de interrogación o dos puntos al final de una cadena.

La puntuación y todo debe estar dentro del archivo de internacionalización, listo para ser enviado a la interfaz de usuario.

Lo único que debe preocupar a la interfaz de usuario es la presentación correcta de este texto listo para ser asignado , como alinear correctamente si es un lenguaje RTL. Pero esa es otra historia y no tiene nada que ver con los archivos de lenguaje de internacionalización de texto plano per se.