ES3038008T3 - Method for automated detection, correction, and translation of un-localized lines - Google Patents

Abstract

Un método para la comprobación periódica de líneas localizadas en el código fuente de la aplicación antes de que la aplicación ensamblada se propague a archivos de mensajes (*.po). Se proporciona una internacionalización automatizada de líneas para todos los idiomas de la aplicación compatibles. Las líneas y sus traducciones en archivos de configuración regional (JSON) se validan con los archivos de mensajes (PO). Las líneas no realizadas se comprueban en el código fuente mediante un marcador de localización. Según el APS, se utiliza una trampa especial (es decir, un gancho) para la utilidad msgmake de APS para obtener datos de localización de un conjunto de herramientas aps_command_line_tools para ensamblar una interfaz de usuario. Las líneas se corrigen y se cargan de nuevo en el archivo "*.po". (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Método para la detección, corrección y traducción automatizadas de líneas no localizadas

Campo técnico

Esta invención se refiere a un método para la detección automatizada de líneas de código no localizadas y, más particularmente, a la detección, corrección y traducción de líneas de código en interfaces de aplicación que cumplen con la Norma de Empaquetado de Aplicaciones (APS, por sus siglas en inglés). La invención se refiere además a un sistema para la detección, corrección y traducción automatizadas de líneas no localizadas.

Antecedentes

Los sistemas de automatización de servicios requieren una gran cantidad de aplicaciones que cumplan con la Norma de Empaquetado de Aplicaciones (APS). La Norma de Empaquetado de Aplicaciones (APS) es una norma que define una tecnología para integrar software de aplicación con plataformas de hospedaje. La integración de una aplicación con dichas plataformas de hospedaje se implementa mediante la creación de unpaquete APSpara la aplicación, y la aplicación se denominaaplicación APSen este caso. El desarrollo en una plataforma APS permite el uso universal de una aplicación en diferentes plataformas de hospedaje. Estas aplicaciones también se implementan en varias regiones del mundo en idiomas y/o dialectos nativos. Para poder utilizar estas aplicaciones, sus interfaces gráficas de usuario(Graphical User Interfaces,GUI) a veces se implementan en el idioma local. Por ejemplo, cuando una GUI puede tener un elemento de texto en inglés cuando se presenta a un usuario en los Estados Unidos (EE. UU.), el mismo elemento de la GUI puede tener el mismo texto traducido al ruso cuando se presenta a un usuario en Rusia. El uso de un idioma local (a diferencia del inglés únicamente) para los elementos de la GUI permite una experiencia de usuario mejorada y personalizada.

La internacionalización (i18n) es el proceso de desarrollo de una aplicación de tal modo que las cadenas y otros bits específicos de la configuración regional (como los formatos de fecha o moneda) se puedan extraer de la aplicación para poder localizarlos fácilmente para idiomas y culturas. La localización (l10n) es el proceso de adaptar las aplicaciones y el texto para permitir su uso en un mercado cultural o lingüístico determinado, proporcionando traducciones y formatos localizados para los bits resumidos. Por ejemplo, hacer que una aplicación estadounidense sea accesible para usuarios australianos o británicos puede requerir algo más que unas cuantas correcciones ortográficas. Sin embargo, para que los usuarios japoneses puedan utilizar una aplicación estadounidense, o para que los usuarios alemanes puedan utilizar una aplicación coreana, será necesario que el software funcione no solo en diferentes idiomas, sino que también utilice diferentes técnicas de entrada y convenciones de presentación.

Desarrollar una GUI (y los elementos de la GUI que contiene) para cada idioma y para cada aplicación no es una propuesta viable. El tiempo, el esfuerzo y el dinero necesarios para desarrollar las denominadas GUI “ nativas del idioma” pueden resultar onerosos cuando se intenta implementar una aplicación en varias regiones del mundo.

Para reducir la carga, las plataformas de software y desarrollo, como por ejemplo la plataforma APS, permiten localizar y traducir los elementos de la GUI. Esto permite que una GUI, cuando se renderice, esté en un idioma nativo de la región (o del usuario). Sin embargo, las traducciones y conversiones tradicionales de los elementos de la interfaz GUI no se presentan de manera uniforme. Esto puede deberse a que el conjunto de caracteres comprendiendo el alfabeto de un idioma es diferente al de otro idioma; el cambio en las características espaciales hace que el texto en el idioma traducido sea más grande (o más pequeño); o hay un significado “perdido en la traducción” .

Además, cuando se desarrolla o mejora una GUI, la cantidad de datos renderizados en la pantalla para el usuario final puede aumentar, incluido cualquier mensaje de texto que el usuario vea como parte de la GUI. En particular, el número de líneas, las marcas de los elementos de la interfaz y los formularios de pantalla tienden a aumentar. Según la Norma APS, todos los elementos de la interfaz de la aplicación deben estar localizados e internacionalizados. Sin embargo, las líneas y los elementos de la interfaz no siempre tienen el formato correcto una vez incluidos en el código de la aplicación. Como resultado, el usuario final puede observar fallas causadas por una localización y traducción parciales de los mensajes dentro de la aplicación.

Por ejemplo, haciendo referencia ahora a la figura 1, se muestra una realización de un método convencional para la traducción de líneas no localizadas de una aplicación compatible con APS, generalmente en 100. El método convencional incluye la etapa 102 de recopilar el código fuente; la etapa 104 de importar la localización a través de publicaciones demsgmake;la etapa 106 de creación de archivos de mensajes de objetos portátiles (.po); la etapa 108 de transferir las publicaciones demsgmakea un redactor técnico que redacta las traducciones para las líneas no localizadas; la etapa 110 de añadir la traducción; la etapa 112 de construir el paquete APS exportando el mensaje localizado en notación de objetos de JavaScript(JavaScript ObjectNotation,JSON); que resulta en 114 con el paquete APS con archivos de internacionalización.

En el método convencional 100, no todas las líneas se pueden presentar y localizar correctamente en la interfaz. Las razones de esto pueden incluir, pero no se limitan a, el formato incorrecto de las localidades, un error del procesador, una clave incorrecta, la falta de traducciones disponibles o errores tipográficos o archivos faltantes relacionados con una localidad adicional, por nombrar algunos ejemplos no limitativos. Esto se traduce en una implementación incompleta de los escenarios requeridos y en altos costos asociados con los controles y verificaciones.

Idealmente, los problemas anteriores se pueden prevenir en la fase de desarrollo de la aplicación. Además, se desean comprobaciones automatizadas y semiautomatizadas de la exactitud de la traducción de los elementos de la GUI. Esto ayudará a mejorar las verificaciones y reducir los costos asociados con la verificación manual. Por último, se desea un método para la detección oportuna de los errores de localización en la administración del ciclo de vida de la aplicación.

La publicación “ Internacionalization and localization” , consultada en Internet el 31 de marzo de 2020 (URL: https://web.archive.org/web/20160910175747/https: //en.wikipedia.org/wiki/Internationalization_and_localization) generalmente describe la internacionalización y la localización. No se describe ningún método para la internacionalización o localización automatizadas. El documento US-2016/009826 A1 se refiere en general a la localización del contenido de la aplicación y, más particularmente, a un método y un sistema para localizar el contenido de la aplicación móvil en una o más localidades diana. El documento EP 1315086 A1 se refiere a un método y una unidad de procesamiento para proporcionar una versión localizada de una aplicación de software que tiene elementos de texto, por ejemplo, para su presentación a un usuario.

Existe la necesidad de un método para la detección, corrección y traslación automatizadas de líneas no localizadas.

Resumen

En consecuencia, la presente descripción se refiere a un método para la detección, corrección y traducción automatizadas de líneas de código no localizadas que evita sustancialmente una o más de las desventajas de la técnica anterior (como se explica más adelante). La presente invención se define según las reivindicaciones independientes. Realizaciones específicas se definen en las reivindicaciones dependientes.

En un aspecto de la presente descripción, se proporciona un método para la verificación periódica de las líneas localizadas en el código fuente de la aplicación antes de que la aplicación ensamblada se propague a archivos de mensajes (*.po). En otra realización, se proporciona una traducción automática de líneas para todos los idiomas de aplicación compatibles. Las líneas y sus traducciones, que se proporcionan en los archivos JSON i18n, se validan con los archivos de mensajes. Según una realización ilustrativa, las líneas no localizadas se comprueban en el código fuente utilizando un marcador de localización. Según la APS, la utilidadaps msgmakeutiliza una trampa especial (es decir, un gancho) para obtener datos de localización de un conjunto de herramientas de línea de comandos deapspara ensamblar una interfaz de usuario.

Breve descripción de los dibujos

La figura 1 muestra un dibujo esquemático de un proceso existente de traducción manual de líneas de código por parte de un escritor técnico.

La figura 2 muestra un dibujo esquemático de un método sugerido para la detección, corrección y traslación automatizadas de líneas no localizadas.

La figura 3 muestra un diagrama de flujo de un método para la detección y recopilación automatizadas de patrones de localización.

La figura 4 muestra un diagrama de flujo de un método para la detección, corrección y traslación automatizadas de líneas no localizadas.

La figura 5 muestra un diagrama de flujo de un método para la detección automática y la validación de líneas de propagación.

La figura 6 muestra un dibujo esquemático de un método para la detección, corrección y traslación automatizadas de líneas no localizadas.

Descripción detallada

Ahora se hará referencia en detalle a las realizaciones preferidas de la presente invención, cuyos ejemplos se ilustran en los dibujos adjuntos.

En al menos una realización de la presente descripción, se proporciona un método para la verificación periódica de las líneas localizadas en el código fuente de la aplicación antes de que la aplicación ensamblada se propague a archivos de mensajes (*.po). En otra realización, se proporciona una internacionalización automatizada de líneas para todos los lenguajes de aplicación compatibles. Las líneas y sus traducciones se validan con los archivos de mensajes (*.po).

Según la realización ilustrativa y con referencia a la figura 2, las líneas localizadas se marcan en el código fuente 202 utilizando un marcador de localización. En una realización que utiliza la APS, se utiliza una trampa especial (es decir, un gancho) para la utilidadaps msgmake204 con el fin de derivar datos de localización de un conjunto de herramientas de línea de comandos deapspara ensamblar una interfaz de usuario. El comandoaps msgmakeextrae las cadenas de traducción en archivos de mensajes (*.po), un archivo por idioma. Un archivo de mensajes .po es un archivo de texto sin formato que representa un solo idioma y contiene todas las cadenas de traducción disponibles y su interpretación (traducción) en el idioma dado. Este archivo es una forma cómoda para que los traductores interpreten las cadenas de traducción en el idioma de destino. El archivo de mensajes .po se compone de muchas entradas, cada una describe la relación entre una cadena original no traducida y su traducción correspondiente:

msgstr“ [La cadena de traducción original está aquí]”

msgstr“ [La cadena de traducción está aquí]”

Utilizando el ejemplo anterior, una traducción en español se puede expresar de la siguiente manera:

msgid “ Diskspace - Us age Only”

msgstr “ Espacio en disco - Solamente Uso”

Según la realización ilustrativa, se utilizan dos formatos ejemplares de un gancho (es decir, un marcador de localización):

El par de guiones bajos para *.java y un único guión bajo para la función *.js es un gancho que hace que una cadena esté disponible para su traducción. Por ejemplo,__(“cadena a traducir” ) hace que el comandoaps msgmakecree el parmsgid “ cadena a traducir"ymsgstr “ cadena traducida"en los archivos.po206. En el caso general, una cadena puede contener parámetros mapeados que no deben traducirse. Los parámetros mapeados deben estar incluidos entre un par de guiones bajos “__” . En el siguiente ejemplo, la cadenaMsgKeycontiene parámetros, cuyos valores deben encontrarse en la cadena de mapeoParamObjects:_(msgKey, paramObjects)

Se apreciará además que el marcador de localización se puede utilizar en un formato corto o completo. Por ejemplo: JavaScript (*.js):

Formato corto: _(“ User__username__created” )

Formato completo: _(“ User username created” , {“username” :”John Smith” })

Java (*.java):

Formato corto: (“ User username created” )

Formato completo: (“ User username created” , {“username” : “John Smith” })

En consecuencia, todas estas líneas se agregan al archivo de mensajes.poy, posteriormente, a JSON de la siguiente manera:

La función__() se utiliza para localizar la cadena @msgKey. Por ejemplo, @msgKey es en realidad una cadena que“ Found__itemsCount__item(s)."Esta cadena contiene el parámetroItemsCount, envuelto por un par de guiones bajos. El parámetro se define mediante la cadena de mapeo{“ itemsCount":counter}.Por lo tanto, siaps msgmakecumple con el siguiente código al analizar un código JavaScript:

_(“ Found__itemsCount__item(s)” , {“ itemsCount” :itemsCount})

genera automáticamente el siguiente par de registros en el archivo de mensajes .po:

msgid“ Found__itemsCount__item(s)”

msgstr” “

El archivo de mensajes.poresultante 206 se considera correcto y se utiliza como base para un diccionario de muestras de localización (es decir, patrones de localización). Dado que la variabilidad del código es bastante alta, es imposible determinar las líneas que deben localizarse en el código fuente del producto con un alto grado de precisión. Según la realización ilustrativa, las líneas del código fuente de las claves que se han escrito en el archivo de mensajes.pode la localidad nativa en_US.po se consideran y recopilan automáticamente como muestras de localización.

Como se muestra en la figura 2, se puede utilizar un analizador de código fuente 208 para revisar varias fuentes de código 202. Una vez que se encuentra una línea con un marcador de localización, el analizador de código fuente 208 guarda todo lo que precede al marcador de localización dentro de la línea actual en una base de datos (es decir, la base de datos 656):

El registro anterior se denomina patrón de localización. Por ejemplo, en lo siguiente:

var warn =_(“Asignarse el servicio ServiceName para empezar a utilizarlo.” , {serviceName: serviceConstants.SERVICE_NAME}, la muestra de localización será“ var warn

Según la realización ilustrativa, las muestras de localización (patrones) se generan según una pluralidad de reglas. En al menos una realización de la presente descripción, si una línea del archivo java * contiene una declaración de la constante de texto (es decir, una “cadena final estática” o “estática final” de texto), la aplicación considera que todo lo colocado antes de la cadena, incluida la palabra “cadena” real, es un patrón de localización. Por lo tanto, para lacadena estática final pública PASSWORD NOT CHANGED=(“ Password Not Changed")el patrón de localización escadena estática final pública.

Cuando no hay texto delante del marcador de localización (por ejemplo, en una cadena multilínea), el analizador de código fuente 208 toma todo lo que se encuentra una línea por encima como un patrón de localización. Si la línea anterior contiene una cadena con el marcador de localización, la aplicación pasa a la siguiente línea anterior. Por ejemplo, para una línea:

return runNotification(apsAccountUuid, apsUserUuid, () -> {

returnbuildNotification(apsAccountUuid, apsUserUuid, entity, domainName, NotificationMessageStalus.inProgress,

__(“Assigning Domain"),

__(“Assigning of domain \"{domain}\" is in progress."),

__(“Assigning of domain\"{domain}\" is in progress. “

“ It can take several minutes to complete."))

.send();

});

el patrón de localización es:

return buildNotification (apsAccountUuid, apsUserUuid, entity, domainName, NotificationMessageStatus.inProgress).

Si la cadena multilínea se encuentra durante una búsqueda basada en un patrón de localización ya generado, el analizador de código fuente 208 lee la cadena hasta el punto y coma, que se interpreta como un final de cadena. Todos los demás casos límite se resuelven durante una revisión del código, por lo que el mecanismo de creación de patrones de localización se implementa dentro de la misma norma. Según una realización ilustrativa, el marcador de localización se añade automáticamente, después de que se forme una lista de patrones de localización. Una vez formada una lista de patrones de localización, el analizador de código fuente 208, utilizando los patrones de localización guardados, busca entradas en todos los archivos con la extensión de archivo particular (por ejemplo, JS). Por ejemplo, si hay unaetiquetade muestra; marcador, a continuación buscar el final de la línea donde se encuentre un marcador de cadena de muestra (por ejemplo, comillas dobles) y, a continuación, extender esta cadena con un marcador de localización si no existe. Por ejemplo:

Etiqueta: “test string” ---> label:_(“test string” )

A continuación, se implementa un proceso de propagación de líneas (en donde todas las líneas de código con un marcador de localización se mueven a archivos PO), a través de la herramientaaps msgmake,como se muestra en la figura 2. En la etapa 204, elaps msgmakefacilita la colocación del contenido entre comillas dentro del archivo de mensajes (*.po) y esto se convierte en una clave de localización.

Después de añadir todas las claves de localización alarchivo de mensajes .pode la localidad nativa (por ejemplo, “en_US.po” ), se inicia un análisis de localización 210. El analizador de configuración regional analiza un archivo de mensajes*poen el idioma nativo para ver todos losmsgIDexistentes. Después de eso, la herramienta compara los archivos de idiomas nativos y adicionales y amplía los archivos de idiomas adicionales con losmsgIDque no aparecen en él. A continuación, se inicia el proceso de internacionalización de líneas 212 utilizando cualquiera de las bibliotecas disponibles configuradas para trabajar con los archivos gettext (*.po) 214. Se apreciará que los archivosgettextse basan en un sistema de internacionalización y localización (i18n) utilizado habitualmente para escribir programas multilingües. Por ejemplo, para el lenguaje de programación Python, se puede utilizar la biblioteca “ Polib” . La API de Google Translate se puede utilizar para la traducción automática de líneas.

Para cadamsgID(las cadenas de losarchivos *poconstan de claves), se envía una solicitud de traducción a un motor de traducción, como Google Translate, que utiliza la API de Google Translate en formato JSON, por citar un ejemplo no limitativo.

Si la solicitud se ejecuta correctamente, el servidor devuelve una respuesta “ OK” y un resultado de traducción en JSON:

Según la realización ilustrativa, la traducción se solicita para todos los idiomas admitidos por la aplicación APS o solo para los idiomas que tienen el archivo de mensajes.popresente en el sistema. La selección de la traducción se realiza según un modo de inicio de script de internacionalización. Las líneas traducidas también se escriben en la base de datos (es decir, la base de datos 656) en el siguiente formato:

Según la realización ilustrativa, las líneas traducidas apropiadas se escriben en los archivosgettextapropiados. A continuación, se inicia el proceso manual de validación de la traducción 218. El Redactor Técnico responsable revisa las cadenas que se tradujeron automáticamente.

En la etapa 220, después de ensamblar la aplicación APS (es decir, el paquete APS 222), el contenido del archivo de mensajes (*.po) se convierte en el archivo de localización *.json.

Según la realización ilustrativa, las líneas se validan entre losarchivos de mensajes .poy JSON 224. Una vez ensamblado el paquete, el script de validación importa todas las claves de localización y los valores de localización correspondientes de losarchivos de mensajes .po.A continuación, el script comprueba si hay un archivo con el mismo nombre y la extensión *.json. Posteriormente, el script compara las claves y los valores cargados en la memoria con las claves y los valores del archivo JSON. Si no se encuentra la clave o el valor, se crea un informe de errores automatizado 226 y se puede enviar a un desarrollador de aplicaciones, por citar un ejemplo no limitativo.

Haciendo referencia ahora a la figura 3, se muestra un diagrama de flujo de un método para comprobar si hay líneas no localizadas en un código fuente que llena una base de datos con muestras de localización, según una realización de la presente descripción. En la etapa 305, losarchivos de mensajes .pose generan mediante una herramientaaps msgmakecomo se ha descrito anteriormente. En al menos una realización de la presente descripción, el comandoaps msgmakeextrae lascadenas de traducciónenarchivos de mensajes .po,un archivo por idioma. Este archivo es una forma cómoda para que los traductores interpreten lascadenas de traducciónen el idioma de destino. La utilidadaps msgmakeutiliza una trampa especial (es decir, un gancho) para obtener datos de localización de un conjunto de herramientas de línea de comandos deapspara ensamblar una GUI.

En la etapa 310, se analiza unarchivo de mensajes .pode localidad nativo. Por ejemplo,en_US.poes unarchivo de mensajes de localidad .popara el idioma inglés(en) enlos Estados Unidos (EE. UU.). El nombre delarchivo de mensajes .potiene el formatoII_CC.po.El código principal de dos letras (ll) se define en la especificación delenguajeISO 639-1. El subcódigo de dos letras (CC) se interpreta según la especificación depaísISO 3166-1. Laparte del idiomasiempre se escribe en minúsculas y la parte del país en mayúsculas. El separador es un guión bajo (“_” ). En al menos una realización de la presente descripción, un archivo demensajes .poes un archivo de texto plano, que representa un solo idioma que contiene todas lascadenas de traduccióndisponibles y su interpretación (traducción) en el idioma dado. Se apreciará que unarchivo de mensajes .popuede estar compuesto por muchas entradas, cada una de las cuales describe la relación entre una cadena original no traducida y su traducción correspondiente:

msgstr“ La cadena de traducción original está aquí”

msgstr “ La cadena traducida está aquí”

En la etapa 320, el proceso determina si una cadenamsgidya existe en una base de datos (por ejemplo, la base de datos 656). Si elmsgidexiste, el proceso vuelve a la etapa 310. De lo contrario, el proceso recopila patrones de localización en la etapa 330. A continuación, el proceso guarda los patrones de localización en la base de datos 656 y envía un informe 212 a una parte responsable, tal como, por ejemplo, un redactor técnico en la etapa 340. Se apreciará que el informe 212 contiene patrones de localización recién añadidos que pueden ser analizados por un desarrollador o redactor técnico para excluirlos y hacer una excepción para no reconocer tales cadenas como patrones de localización. En la etapa 350, el proceso determina si ha llegado al final del archivo(End Of File,EOF) del archivo demensajes .po.Si se ha alcanzado el EOF, el proceso finaliza en la etapa 360. De lo contrario, el proceso vuelve a la etapa 310.

Haciendo referencia ahora a la figura 4, se muestra un diagrama de flujo de un método para la internacionalización automatizada de líneas en un código fuente que llena una base de datos con muestras de localización, según una realización de la presente descripción. En la etapa 405, losarchivos de mensajes .pose generan mediante una herramientaaps msgmakecomo se ha descrito anteriormente. Al menos en una realización, los archivos *po se pueden recuperar de la etapa anterior después de trabajar con el analizador de código fuente (segunda iteración de la etapa 204). En al menos una realización de la presente descripción, el comandoaps msgmakeextrae lascadenas de traducciónenarchivos de mensajes .po,un archivo por idioma. Este archivo es una forma cómoda para que los traductores interpreten lascadenas de traducciónen el idioma de destino. La utilidadaps msgmakeutiliza una trampa especial (es decir, un gancho) para obtener datos de localización de un conjunto de herramientas de línea de comandos deapspara ensamblar una GUI.

En al menos una realización de la presente descripción, el proceso crea automáticamente una pluralidad dearchivos de mensajes .popara cada localidad en la que se desea una traducción. Se apreciará además que elarchivo de mensajes .popara cada localidad comprende cadamsgidque necesita traducirse. En la etapa 410, se analiza unarchivo de mensajes .pode localidad nativa como se describe en la etapa 310. Si, en la etapa 415, elmsgidexiste en una localidad adicional, el proceso envía elmsgida través de una solicitud a un motor de traducción, tal como, por ejemplo, la API Google T ranslate, a través de la red 658 en la etapa 430, y recibe una cadena traducida. De lo contrario, el proceso extiende la localidad adicional 420 mediante elmsgid (es decir,el proceso agrega elmsgida la localidad adicional si es necesario) y pasa a la etapa 410. A continuación, en la etapa 440, el proceso guarda las cadenas traducidas en un archivo de mensajes, proporcionándose el archivo de mensajes para cada configuración regional adicional y en una base de datos (por ejemplo, la base de datos 656) y envía un informe. En la etapa 450, el proceso comprueba si ha llegado al final del archivo (EOF) delarchivo de mensajes .po.Si se ha alcanzado el EOF, el proceso finaliza en la etapa 460. De lo contrario, el proceso vuelve a la etapa 410.

Haciendo referencia ahora a la figura 5, se muestra un diagrama de flujo de un método para la validación de líneas entre losarchivos de mensajes .poy JSON, según la realización ilustrativa. En la etapa 505, el proceso adquiere unmsgiddelarchivo de mensajes .popara una localidad nativa. En la etapa 510, el proceso analiza un archivo de referencia de localidad (es decir, archivos JSON i18n) para todas las localidades existentes. En la etapa 520, el proceso determina si una clave/valor en elarchivo de mensajes .poes igual al archivo de referencia de localidad (es decir, el archivo JSON i18n) excepto la configuración regional nativa donde los valores están vacíos por defecto. Por lo tanto, para la configuración regional nativa, solo compara los valores de las claves. Si la clave/valor delarchivo de mensajes .poes igual al archivo de referencia de localidad, el proceso determina si el archivo JSON (archivo de referencia de localidad) ha llegado al final del archivo (EOF) en la etapa 530. Si el archivo JSON ha llegado al final del archivo (EOF), el proceso finaliza en la etapa 560. De lo contrario, el proceso pasa a la etapa 510. Si, en la etapa 520, la clave/valor del archivo demensajes .poNO es igual al archivo de referencia de localidad, el proceso guarda las cadenas ausentes en una base de datos 656 y envía un informe a una parte responsable (por ejemplo, el redactor técnico responsable) en la etapa 540 y pasa a la etapa 510. En la etapa 550, los errores se procesan manualmente.

Haciendo referencia a la figura 6, se muestran un sistema y componentes para la detección, corrección y traslación automatizadas de líneas no localizadas, generalmente en 650. Esta descripción se presenta en términos de programas, estructuras de datos o procedimientos ejecutados en un ordenador o red de ordenadores. Los programas de software implementados por el sistema pueden escribirse en cualquier lenguaje de programación: interpretado, compilado o de otro modo. Estos lenguajes pueden incluir, pero no se limitan a, PHP, ASP.net, HTML, HTML5, Ruby, Perl, Java, Python, C++, C#, JavaScript, y/o el lenguaje de programación Go. Debe apreciarse, por supuesto, que un experto en la técnica apreciará que se pueden utilizar otros lenguajes en su lugar, o en combinación con lo anterior, y que también se pueden utilizar marcos de aplicaciones web y/o móviles, tales como, por ejemplo, Ruby on Rails, Node.js, Zend, Symfony, Revel, Django, Struts, Spring, Play, Jo, Twitter Bootstrap y otros. Debe apreciarse además que los sistemas y métodos descritos en la presente memoria pueden incorporarse en un software como servicio disponible a través de una red informática, tal como, por ejemplo, Internet. Además, la presente descripción puede habilitar servicios web, interfaces de programación de aplicaciones y/o arquitecturas orientadas a servicios a través de una o más interfaces de programación de aplicaciones o de otro modo.

La figura 6 muestra un sistema para la detección, corrección y traslación automatizadas de líneas no localizadas. En al menos una realización de la presente descripción, el sistema comprende una GUI 652 de usuario, un servidor 654, una base de datos 656 y una red informática 658.

La GUI 652 de usuario puede configurarse para transmitir información y, en general, interactuar con un servicio web y/o una infraestructura de interfaz de programación de aplicaciones alojada en el servidor 654 a través de la red informática 658. La GUI 652 de usuario puede incluir un navegador web, una aplicación móvil, un enchufe(socket)o un túnel u otro software conectado a la red, de modo que la comunicación con la infraestructura de servicios web en el servidor 654 sea posible a través de la red informática 658.

La GUI 652 de usuario incluye uno o más ordenadores, teléfonos inteligentes, tabletas, tecnología portátil, dispositivos informáticos o sistemas de un tipo bien conocido en la técnica, tales como un ordenador central, una estación de trabajo, un ordenador personal, un ordenador portátil, un ordenador portátil, un teléfono móvil, un reproductor de MP3 o un asistente digital personal. La GUI 652 de usuario comprende el software, el hardware y los componentes que se le ocurran a un experto en la técnica, tales como, por ejemplo, uno o más microprocesadores, sistemas de memoria, dispositivos de entrada/salida, controladores de dispositivos y similares. La GUI 652 de usuario también comprende uno o más medios de entrada de datos (no mostrados en la figura 6) operables por los clientes de la GUI 652 de usuario para la entrada de datos, tales como, por ejemplo, control de voz o audio, un dispositivo señalador (tal como un ratón), teclado, pantalla táctil, micrófono, reconocimiento de voz y/u otros medios de entrada de datos conocidos en la técnica. La GUI 652 de usuario también comprende un medio de visualización que puede comprender varios tipos de pantallas conocidas, tales como pantallas de diodos de cristal líquido, pantallas de diodos emisores de luz y similares, en las que la información puede mostrarse de una manera perceptible para los clientes. Se apreciará que la GUI 652 de usuario puede comprender además el software, el hardware y los componentes que se le ocurran a un experto en la técnica para realizar operativamente las funciones asignadas a la GUI 652 de usuario según la presente descripción.

La base de datos 656 está configurada para almacenar información generada por el sistema y/o recuperada de una o más fuentes de información. En al menos una realización de la presente descripción, la base de datos 656 puede estar “asociada con” el servidor 654 donde la base de datos 656 reside en el servidor 654. La base de datos 656 también puede estar “ asociada con” el servidor 654, donde la base de datos 656 reside en un servidor o dispositivo informático remoto del servidor 654, siempre que el servidor o dispositivo informático remoto sea capaz de transferir datos bidireccionalmente con el servidor 654, como, por ejemplo, en Amazon AWS, Rackspace u otra infraestructura virtual o cualquier red empresarial. En al menos una realización de la presente descripción, el servidor remoto o dispositivo informático en donde reside la base de datos 656 está conectado electrónicamente al servidor 654 de tal modo que el servidor remoto o dispositivo informático es capaz de realizar una transferencia de datos bidireccional continua con el servidor 654.

Con fines de claridad, la base de datos 656 se muestra en la figura 6 y se denomina en la presente memoria una base de datos única. Los expertos en la técnica apreciarán que la base de datos 656 puede comprender una pluralidad de bases de datos conectadas por sistemas de software de un tipo bien conocido en la técnica, que en conjunto son operables para realizar las funciones delegadas a la base de datos 656 según la presente descripción. La base de datos 656 también puede ser parte de una arquitectura de datos distribuidos, tal como, por ejemplo, una arquitectura Hadoop, para servicios de big data. La base de datos 656 puede comprender una arquitectura de base de datos relacional, NoSQL, OLAP u otra arquitectura de base de datos de un tipo conocido en la técnica de las bases de datos. La base de datos 656 puede comprender uno de los muchos sistemas de gestión de bases de datos bien conocidos, tales como, por ejemplo, SQL Server de MICROSOFT, ACCESS de MICROSOFT, MongoDB, Redis. Hadoop, los sistemas de administración de bases de datos DB2 de IBM o los sistemas de administración de bases de datos disponibles en ORACLE o SYBASE. La base de datos 656 almacena de forma recuperable la información que se comunica a la base de datos 656 desde la GUI 652 del usuario o el servidor 654.

Habiendo descrito de este modo una realización, será evidente para los expertos en la técnica que se han logrado ciertas ventajas del método y sistema descritos. También debe apreciarse que se pueden realizar diversas modificaciones, adaptaciones y realizaciones alternativas de las mismas dentro del alcance de la presente descripción. La descripción se define además mediante las siguientes reivindicaciones.

Claims (13)

REIVINDICACIONES

1. Un método para la detección, corrección y traducción automatizadas de líneas no localizadas de código fuente (202) en interfaces de aplicaciones que cumplen con la Norma de Empaquetado de Aplicaciones, comprendiendo el método las etapas de:

a. recibir al menos un archivo de código fuente;

b. generar al menos un archivo (206) de mensajes a partir de al menos un archivo de código fuente para al menos una primera configuración regional, comprendiendo al menos un archivo (206) de mensajes al menos un identificador de mensaje y al menos una primera configuración regional del identificador de mensaje en al menos un archivo de código fuente;

c. analizar cada uno de al menos un archivo (206) de mensajes y recuperar al menos un identificador de mensaje, comprobar al menos un identificador de mensaje para ver si ya existe en una base de datos de identificadores de mensajes;

d. generar y guardar en la base de datos de identificadores de mensajes una pluralidad de muestras de localización utilizando al menos el contexto de al menos un identificador de mensaje en al menos un archivo de código fuente;

e. comprobar uno de al menos un identificador de mensaje para ver si existe en al menos una configuración regional adicional (420) que sea diferente de la primera configuración regional y, si existe, continuar con la etapa (g), si no es así, continuar con la etapa (f);

f. extender al menos una configuración regional adicional mediante una de las al menos un identificador de mensaje, y volver a la etapa (e) para comprobar la siguiente de al menos un identificador de mensaje hasta que se hayan comprobado todas las identificaciones de mensaje de al menos un identificador de mensaje;

g. solicitar una traducción a un motor de traducción y recibir una cadena de código traducida del motor de traducción, registrando la cadena de código traducida en la base de datos de identificadores de mensajes;

h. generar un informe para una parte revisora;

i. generar una pluralidad de archivos de presentación para su presentación a través de una GUI; j. analizar la pluralidad de archivos de presentación para verificar si la pluralidad de archivos de presentación tiene el mismo identificador de mensaje y cadena de código traducida que al menos una configuración regional adicional;

k. actualizar la pluralidad de archivos de presentación mediante el identificador de mensaje y la cadena de códigos traducidos si el identificador de mensaje y la cadena de códigos traducidos no están en la pluralidad de archivos de presentación;

l. corregir los errores de traducción de la pluralidad de archivos de presentación e informar sobre los cambios a la parte revisora.

2. El método de la reivindicación 1, comprendiendo además validar el archivo (206) de mensajes contra la notación de objetos de JavaScript, JSON, mediante:

analizar archivos JSON para todas las localidades existentes; y

enviar un informe y procesar los errores según el informe.

3. El método de la reivindicación 1, comprendiendo además adquirir muestras de localización y guardarlas en la base de datos.

4. El método de la reivindicación 1, en donde al menos un primer archivo de mensajes de configuración regional (206) es el archivo en_US.po.

5. El método de la reivindicación 1, en donde la traducción se solicita utilizando una interfaz de programación de aplicaciones de utilidad de traducción.

6. El método de la reivindicación 1, en donde la corrección de los errores de traducción comprende corregir automáticamente los errores encontrados por el script y corregir manualmente los errores encontrados por los errores de propagación entre los archivos de mensajes y los archivos locales.

7. Un sistema (650) para la detección, corrección y traducción automatizadas de líneas no localizadas, comprendiendo el sistema una GUI (652) de usuario, un servidor (654), una base de datos (656) y una red informática (658),

en donde la GUI (652) de usuario comprende software, hardware y componentes, en donde la base de datos (656) está configurada para almacenar información generada por el sistema y/o recuperada de una o más fuentes de información,

en donde el sistema está diseñado para ejecutar el método de cualquiera de las reivindicaciones 1 a 6.

8. El sistema de la reivindicación 7, en donde el hardware se selecciona de entre uno o más ordenadores, uno o más teléfonos inteligentes, una o más tabletas, tecnología portátil o uno o más dispositivos informáticos.

9. El sistema de la reivindicación 7, en donde uno o más ordenadores se seleccionan entre un ordenador central, una estación de trabajo, un ordenador personal, un ordenador portátil y un ordenador manual; o la tecnología portátil es un reproductor MP3, un teléfono celular o un asistente digital personal.

10. El sistema de una cualquiera de las reivindicaciones 7 a 9, en donde la GUI (652) de usuario comprende uno o más medios de entrada de datos operables por los clientes de la GUI (652) de usuario para la entrada de datos.

11. El sistema de una cualquiera de las reivindicaciones 7 a 10, en donde la GUI (652) de usuario comprende un medio de visualización.

12. El sistema de una cualquiera de las reivindicaciones 7 a 11, en donde la base de datos (656) reside en el servidor (654).

13. El sistema de una cualquiera de las reivindicaciones 7 a 11, en donde la base de datos (656) reside en un servidor o dispositivo informático remoto del servidor (654), siempre que el servidor remoto o dispositivo informático sea capaz de transferir datos bidireccionalmente con el servidor (654).