Utopía y realidad de los proyectos de localización. Un … · 2019-10-23 · 3 Resumen: Este...

2

TRABAJO DE INVESTIGACIÓN

Utopía y realidad de los proyectos de localización.

Un acercamiento entre los desarrolladores y los

localizadores.

Grado en Traducción e Interpretación

Facultad de Filosofía y Letras

Universidad Autónoma de Madrid

Mireia Álvarez Moros

3

Resumen:

Este trabajo tiene por objeto presentar las prácticas que idealmente deberían llevarse a

cabo en las empresas de desarrollo de software o creación de páginas web para facilitar

lo máximo posible la labor concreta del localizador o traductor dentro del proceso de

localización, así como una serie de soluciones o conocimientos complementarios que

podrían ayudar al traductor a subsanar las posibles deficiencias del proceso de

internacionalización o de las fases previas a su labor.

Abstract:

This paper is aimed at offering a number of actions that should be implemented in order

to make translators’ job, which is part of the localization process, as easy as possible.

Besides, it also aims to gather a series of possible solutions or complementary skills that

could help translators to close gaps in the internationalization process.

Aviso legal:

Aviso legal © Mireia Álvarez Moros, 2018. Todos los derechos reservados.

4

Índice.

Contenido

1. Introducción:......................................................................................................................... 7

2. Estructura: ............................................................................................................................ 8

3. Un poco de historia: .............................................................................................................. 9

3.1. ¿Cuándo surge la localización? ....................................................................................... 9

3.2. Cambios de tendencias y qué implican para los localizadores .......................................... 9

4. ¿En qué se diferencia la localización de la traducción? ........................................................ 10

5. ¿Por qué es importante localizar? ........................................................................................ 11

5.1. ¿Por qué se localiza? .................................................................................................... 11

5.2. ¿Qué pasa si no se lleva a cabo la localización? ............................................................ 11

6. ¿Qué hay que adaptar? ........................................................................................................ 12

7. ¿Cómo se realizan esas adaptaciones? ................................................................................. 15

7.1. Prácticas fundamentales: .............................................................................................. 15

7.2. Otras pautas ................................................................................................................. 21

8. Internacionalización ............................................................................................................ 22

8.1. ¿En qué consiste la internacionalización? ..................................................................... 22

8.2 ¿Qué pasa si no se internacionaliza? .............................................................................. 23

8.3. ¿Por qué no siempre se internacionaliza antes de localizar? ........................................... 23

9. ¿Qué es necesario para ser un buen localizador? .................................................................. 24

10. Básicos de programación: .................................................................................................. 26

10.1. Introducción ............................................................................................................... 26

10.2. ¿Qué es un lenguaje de programación?: ...................................................................... 26

10.3. Lenguajes compilados y lenguajes interpretados ......................................................... 27

10.4. Diferencia entre los lenguajes de programación y los lenguajes de marcado: ............... 28

10.5. Lenguajes de programación más empleados y áreas de utilización: ............................. 29

10.6. Variables, lenguajes tipados y lenguajes no tipados: .................................................... 31

11. Estudio.............................................................................................................................. 35

11.1. Introducción ............................................................................................................... 35

11.2. Aplicación de escritorio GnuCash .............................................................................. 37

11.2.1. Presentación: ....................................................................................................... 38

11.2.2. ¿Están las cadenas de texto separadas del código fuente o incrustadas en el mismo?

............................................................................................................................. ................ 39

5

11.2.3. ¿Están los estilos, colores y fuentes separados del código fuente o incrustados en el

mismo? ........................................................................................................................... 41

11.3.4. Comentarios ........................................................................................................ 42

11.2.5. Glosarios, memorias de traducción, guías de estilo: .............................................. 45

11.2.6. ¿Están las cadenas traducibles marcadas? ............................................................. 47

11.2.7. ¿Son los nombres de las variables significativos? ................................................. 48

11.2.8. Codificación ........................................................................................................ 49

11.2.9. Placeholders: ....................................................................................................... 49

11.2.10. ¿Hay capturas de pantalla o vídeos que requieran localización? .......................... 50

11.2.11. ¿Tienen las imágenes, gráficos, iconos, etc. texto incrustado? ............................. 55

11.2.12. Selección del idioma: ......................................................................................... 56

11.3. Aplicación de escritorio Notepad++ ........................................................................... 59

11.3.1. Introducción: ........................................................................................................... 60


............................................................................................................................................. 60


mismo? ........................................................................................................................... 63

11.3.4. Comentarios ........................................................................................................ 65




11.3.8. Codificación ........................................................................................................ 69

11.3.9. Placeholders ........................................................................................................ 71


11.3.11. ¿Tienen las imágenes, gráficos, etc. texto incrustado?......................................... 73


11.3.13. Errores ............................................................................................................... 75

11.4. Aplicación móvil Pamplona Negra ............................................................................. 77

11.4.1. Introducción: ....................................................................................................... 78


¿Y los estilos, colores y fuentes? ..................................................................................... 80

11.4.3. Comentarios ........................................................................................................ 84




6

11.4.7. Codificación ........................................................................................................ 87

11.4.8. Placeholders: ....................................................................................................... 87

11.4.9. ¿Hay capturas de pantalla o vídeos que requieran localización? ............................ 87

11.4.10. ¿Tienen las imágenes, gráficos, etc. texto incrustado?......................................... 88


11.5. Aplicación móvil GnuCash para Android ................................................................... 90

11.5.1. Introducción: ....................................................................................................... 91


............................................................................................................................. ................ 91


mismo? ........................................................................................................................... 93

11.5.4. Comentarios ........................................................................................................ 96


11.5.6. ¿Están las cadenas traducibles marcadas? ........................................................... 103

11.5.7. ¿Son los nombres de las variables significativos? ............................................... 104

11.5.8. Codificación ...................................................................................................... 104

11.5.9. Placeholders: ..................................................................................................... 105

11.5.10. ¿Hay capturas de pantalla o vídeos que requieran localización? ........................ 107

11.5.11. ¿Tienen las imágenes, gráficos, etc. texto incrustado?....................................... 108

11.5.12. Selección del idioma: ....................................................................................... 109

11.6. Página web Electronjs.org ........................................................................................ 110

11.6.1. Introducción: ..................................................................................................... 111


............................................................................................................................. .............. 112


mismo? ......................................................................................................................... 116

11.6.4. Comentarios ...................................................................................................... 119

11.6.5. Glosarios, memorias de traducción, guías de estilo: ............................................ 120



11.6.8. Codificación ...................................................................................................... 121




11.7. Página web Phalcon.com .......................................................................................... 127

7

11.7.1. Introducción: ..................................................................................................... 128


............................................................................................................................. .............. 128


mismo? ......................................................................................................................... 131

11.7.4. Comentarios ...................................................................................................... 132

11.7.5. Glosarios, memorias de traducción, guías de estilo: ............................................ 134



11.7.8. Codificación ...................................................................................................... 135

11.7.9. Placeholders: ..................................................................................................... 136

11.7.10. ¿Hay capturas de pantalla o vídeos que requieran localización? ........................ 137



11.7.13. Errores ............................................................................................................. 140

11.8. Conclusiones del estudio: ......................................................................................... 141

12. Sugerencias para el acercamiento de los localizadores o traductores y los desarrolladores:

................................................................................................................................................... 143

13. Bibliografía: .................................................................................................................... 146

8

1. Introducción:

El presente trabajo de investigación surge motivado por una conversación que mantuve

meses atrás con un amigo desarrollador. Él me contaba que había participado en el

desarrollo de una aplicación móvil que se iba a utilizar en un evento cultural de su

ciudad natal y que dicha aplicación se iba a traducir del español al euskera. Ante esto,

rápidamente me surgió la duda de si habían internacionalizado la aplicación, añadido

comentarios para los traductores en el código fuente o implementado pautas necesarias

para llevar a cabo el proceso de localización. Mi amigo, atónito ante mi pregunta, me

contestó que tan solo añadían comentarios para otros desarrolladores, pero que jamás

había oído que en determinadas situaciones en las que la aplicación se va a traducir y

por ende, adaptar a otra cultura, puede ser muy conveniente añadir comentarios para

proporcionar más contexto a los traductores, así como para darles ciertas pautas que les

ayudarán y guiarán en su labor.

Esta conversación me hizo pensar en que una situación así no podía ser única, y que

como él, seguramente muchos desarrolladores apenas dediquen un momento de sus

pensamientos a la labor del traductor o incluso ni siquiera sepan de la existencia de la

misma a pesar de que, al fin y al cabo, hablamos de una labor que se sitúa al lado de la

suya propia y la complementa.

A la nada esperanzadora respuesta de mi amigo se suma que, como es ampliamente

conocido entre los traductores, la localización es uno de los ámbitos que más se

caracteriza por la gran falta de contexto con la que se debe trabajar. Por todos estos

factores, el tema principal sobre el que va a versar este trabajo consiste en una

presentación de todas aquellas acciones que los desarrolladores podrían y deberían

llevar a cabo para facilitar la labor de los traductores, así como de todos los

conocimientos que pueden servir de gran ayuda a los localizadores para subsanar las

deficiencias de este ámbito.

El motivo primordial por el que considero muy necesario abordar un tema como el que

aquí se expone es que, en comparación con otras áreas de la traducción y a pesar de que

no estamos ante una disciplina del todo nueva, no existe demasiada documentación

sobre la localización en general -y especialmente en español-. Además, mucho más

difícil resulta encontrar publicaciones sobre localización que se centren en intentar

lograr un acercamiento de posturas entre los desarrolladores y los localizadores o que

traten exclusivamente sobre los conocimientos que podrían ayudar al traductor a

subsanar las posibles deficiencias del proceso de internacionalización.

Por su temática, este trabajo está dirigido tanto a cualquier persona que desee iniciarse

en el mundo de la localización y conocer un poco más sobre el mismo, como a aquellos

traductores ya inmersos en la localización que deseen diversificar su actividad y ofrecer

un servicio lo más completo posible, de manera que puedan cubrir la totalidad o el

mayor número de fases posibles de dicho proceso de adaptación. No obstante, dado

que, como se explica más adelante, la finalidad del estudio que comprende este trabajo

de investigación es presentar una serie de prácticas que podrían mejorarse o

9

implementarse con el fin de facilitar la labor de los localizadores, este también podría

ser un recurso de gran utilidad para gestores de localización, dirigentes de empresas de

desarrollo de software o desarrolladores implicados en labores de internacionalización,

pues al fin y al cabo, el propósito último de este trabajo no es otro que provocar un

acercamiento entre los profesionales que desarrollan el software y aquellos que se

encargan de localizarlo.

2. Estructura:

Para abordar el objeto de este proyecto, he decidido estructurarlo en dos en dos partes

principales. Cabe señalar de antemano que la segunda de ellas constituye la parte más

importante y destacada, ya que consiste en un estudio cualitativo y cuantitativo en el

que se van a someter a análisis una serie de aplicaciones móviles, programas de

escritorio y páginas web traducidos a otros idiomas, con el fin de determinar la

presencia o ausencia de una serie de elementos fundamentales para la localización y de

entre los que destacan los comentarios destinados a los traductores.

No obstante, de manera previa al estudio y para que sirva de contexto y apoyo al

mismo, he considerado oportuno realizar una introducción y aproximación al campo de

la localización –que actúa de primera parte del presente trabajo- a través de una breve

explicación de los conceptos de localización e internacionalización, así como de una

serie de conceptos básicos de programación. En relación con esto, también he llevado a

cabo una presentación de los factores más destacados que deben adaptarse en el proceso

de localización y una explicación bastante exhaustiva de las prácticas previas que son

necesarias y aconsejables para llevar a cabo dicha adaptación.

Una vez concluida la primera parte, de la segunda parte cabe destacar que casi todos los

productos que se van a someter a análisis son de código abierto. Como bien se ha

comentado, el análisis de este material tiene por objeto examinar la presencia o ausencia

de una serie de factores preestablecidos, que además se describirán y explicarán en el

marco contextual de este trabajo.

Por último, para complementar el estudio y dar soluciones viables a las posibles

deficiencias o carencias detectadas en el mismo, también he creído oportuno realizar

una recopilación de sugerencias que permitirían el acercamiento entre los

desarrolladores y los localizadores y entre las que se incluyen algunos conocimientos

que podrían ayudar al traductor a enfrentarse a la labor de localización.

10

3. Un poco de historia:

3.1. ¿Cuándo surge la localización?:

En la década de 1980 aparecieron los primeros ordenadores de sobremesa, y el aumento

de la presencia de las tecnologías -y por ende del software- en la vida de los usuarios

fue tremendamente notable; el uso de las mismas ya no se limitaba al ámbito académico

o a centros tecnológicos, de investigación, etc. como años atrás, sino que cada vez era

más normal contar con un ordenador en el hogar. Esto derivó en que las compañías

encargadas del desarrollo de programas informáticos vieran cada vez más necesario

adaptar sus productos a los mercados internacionales con el fin de llegar a un mayor

número de personas. Así pues, por ejemplo, los procesadores de texto no solo debían

tener un interfaz que se correspondiese con la lengua materna del usuario que los

emplease, sino que además era necesario que pudieran procesar y producir conjuntos de

caracteres en dichos idiomas, así como contar con correctores ortográficos que

atendiesen a las características propias de los mismos (Esselink, 2003).

Fue a partir de esta necesidad de adaptación de los productos de software a distintas

culturas metas cuando surgió lo que hoy en día se conoce como «localización»,

préstamo del término inglés localization, pues como bien señala Roturier (2015, 1) los

países a los que se dirigen dichas adaptaciones reciben el nombre de locales.

3.2. Cambios de tendencias y qué implican para los localizadores:

Desde la llegada de los ordenadores a los hogares, la situación ha cambiado bastante.

Mientras que los programas informáticos han supuesto durante décadas el principal -y

prácticamente el único- producto que las compañías de software desarrollaban y los

usuarios adquirían, en la actualidad este tipo de software retrocede cada vez más para

dejar paso a los servicios alojados en la nube. Además, hace unos años, lo más común

era que las empresas de software se centrasen en una única plataforma, pero en la

actualidad, la aparición de los servicios alojados en la nube, sumada a la revolución de

los smartphones y tabletas, ha provocado que el número de plataformas que deben

abarcar estas empresas sea considerablemente superior (Roturier 2015, 17 y 185-186).

Por otra parte, mientras que durante los primeros años eran los propios desarrolladores

los que se encargaban de la localización, poco a poco se dieron cuenta que lo mejor era

externalizar este servicio para poder centrarse plenamente en su labor principal. Fue así

como durante los años noventa comenzaron a surgir las primeras compañías dedicadas a

la localización, siendo INK una de las primeras en ofrecer servicios de localización

entre los que se incluían labores de ingeniería, traducción y gestión de los proyectos de

localización multilingües (Esselink, 2003).

11

Como es evidente, todos estos cambios de tendencia influyen en la labor de localización

y del localizador, de manera que, mientras que en el pasado los programas informáticos

se lanzaban al mercado después de una larguísima labor de desarrollo y localización y

los usuarios debían adquirir las actualizaciones cuando estas salían al mercado tras

varios meses -o incluso años- para poder seguir disfrutando de todas las funcionalidades

de dichos programas, en la actualidad esto es bien distinto.

Como bien hemos dicho, en el presente, el número de plataformas existentes es mucho

mayor. Además, según Roturier (2015, 6-7), el contenido se desarrolla mucho más

rápido y tanto las aplicaciones móviles -entendiendo como aplicaciones móviles las

aplicaciones diseñadas para smartphones y tabletas- como los servicios alojados en la

nube ponen actualizaciones a disposición del usuario cada mes, cada semana e incluso

cada día. La consecuencia de esto, indica este mismo autor, son encargos de traducción

que suponen un mayor volumen de trabajo y fechas de entrega mucho más ajustadas,

pero también una carga mucho menor en lo que a cada encargo se refiere. Esto último se

explica porque, como bien puntualiza Pablo Muñoz en su blog, es bastante habitual que

la traducción de las actualizaciones se encargue al mismo traductor que realizó la

traducción inicial, por lo que aunque el número de encargos de traducción sea superior,

muchas veces tan solo habrá que realizar unas pocas modificaciones.

Roturier (2015, 8) incide además en la necesidad de que los localizadores actuales se

adapten a tendencias también crecientes como la utilización cada vez más frecuente de

la traducción automática, lo cual deriva en que cada vez sea más habitual realizar una

labor de posedición en lugar de una traducción desde cero, o el surgimiento de métodos

colaborativos de traducción y localización que se sirven de plataformas como Transifex,

Crowdin o Lingotek, a las que, como resulta evidente, los localizadores deben

habituarse.

4. ¿En qué se diferencia la localización de la traducción?

Hurtado Albir (2011, 41) define la traducción como «un proceso interpretativo y

comunicativo consistente en la reformulación de un texto con los medios de otra lengua

que se desarrolla en un contexto social y con una finalidad determinada».

Basta con leer esta definición para darse cuenta de que en realidad la localización va

muchísimo más allá de la traducción, pues no se limita a la reformulación de un texto ni

se queda en el aspecto meramente lingüístico.

Según Esselink (2003, 1), la localización “revolves around combining language and

technology to produce a product that can cross cultural and language barriers”.

12

Además, como aclara Singh (2012, 128), “International software applications and

international websites must be translated into different languages, but they must also be

customized to locale-specific requirements”.

Sandrini (2008, 2), por su parte, determina todo lo que para él implica la localización:

“Localizing a product means adapting the linguistic and cultural specifics of context (text, images,

voice sequences, etc.) to a given geographical or demographic locale. It includes adapting content

to the local conventions for such features as date and time formats, currencies, numbers, language,

colour coding, cultural choices or writing systems.”

Resulta evidente entonces que la traducción es tan solo la punta del iceberg dentro de la

localización, a menudo abreviada como l10n.

5. ¿Por qué es importante localizar?

5.1. ¿Por qué se localiza?

Roturier (2015, 4-5) considera que existen varios motivos para localizar. Entre estos

cabe destacar los siguientes:

- Una mayor cuota de mercado para las empresas dedicadas al desarrollo de

software.

- Alcanzar a un mayor número de clientes y «retenerlos» para que no desinstalen

una aplicación o cierren una página web al instante y busquen otra mejor.

- La existencia de gran cantidad de usuarios interesados en localizar aplicaciones

o páginas web de manera altruista.

- Y, el motivo que consideramos especialmente importante, que es reducir el

número de aquellos que Pym (2004, 91) llama “excluded locales”, “users who are

never given the chance to gain access to information in a language they can

understand”.

5.2. ¿Qué pasa si no se lleva a cabo la localización?

A todo lo anterior se suma el hecho de que no adaptar un producto a un mercado (o no

tener los conocimientos y formación suficientes y necesarios para hacerlo) puede

suponer un coste enorme para el creador o empresa encargados de su desarrollo. No son

pocos los casos de compañías se han visto obligadas a retirar del mercado todas las

existencias de un determinado producto como consecuencia de las críticas recibidas y

polémica generada por no haber realizado una adecuada labor de localización. Un

ejemplo de esto, en este caso directamente relacionado de la traducción como parte del

proceso de localización, es el que presenta Best (2004b) y que Singh recoge en su libro

(2011, 88): “a Spanish-language version of Windows XP, destinated for Latin American

13

markets, asked users to select their gender between “not specified”, “male” or “bitch”,

because of an unfortunate error in translation”.

6. ¿Qué hay que adaptar?

Como bien se ha señalado previamente, la traducción es tan solo uno de los aspectos

que se incluyen dentro de la nada simple labor de localización:

“The most well-known aspect of localization is the localization of the language, the translation, but

localization also covers a lot of other aspects, ranging from the decimal character used, the

thousands separator used, whether the week starts on Sunday or Monday, or whether other icons or

symbols are needed, and countless other aspects. Most of these should be considered as important

as the translation. The translation is just one of several steps needed for making the software

usable to people around the world. If the user should have difficulties understanding for example

the display of a decimal number, then the application still isn't accessible. Even if the user does

understand it but it is presented in a, from his or her perspective, very strange and inconvenient

format, then the application still isn't accessible. Other similar applications that can present the

values correctly will most likely be preferred. Worse, the user might even interpret the value

wrongly, like for example with different and ambiguous date formats or different decimal and

thousands separators, in which case the end result can be disastrous.” (AA.VV, 2017).

Así pues, resulta oportuno presentar todos aquellos aspectos que es especialmente

necesario adaptar en el proceso de localización. Para dicha presentación, se ha llevado a

cabo una recopilación de todos los elementos que varios autores (entre los que se

incluyen Roturier o Singh) y el World Wide Web Consortium aconsejan someter a

adaptación y se ha procedido a la selección de todos aquellos que resultan más

relevantes para este trabajo:

1) FORMATOS (fechas, horas, divisas, números, direcciones y teléfonos): Tal y como

expone Singh (2012, 136), el formato en el que se presentan las fechas varía entre los

distintos países. Así, mientras que en España y en la mayor parte de países europeos el

formato se corresponde con dd/mm/aaaa, en Estados Unidos el formato es mm/dd/aaaa

y en Japón aaaa/mm/dd. Este es un factor realmente importante, pues por ejemplo, un

usuario español podría entrar en una página web que se ha desarrollado en Estados

Unidos y que aparentemente se ha localizado al español, sin embargo, si no se ha

adaptado el formato de fecha, no solo deberíamos afirmar que existen deficiencias en la

localización de esa página web, sino que además existe la posibilidad de que surjan

confusiones que pueden ser tremendamente graves si hablamos de fechas que indican el

plazo para presentar documentos oficiales, solicitudes o similares.

Lo mismo sucede con las horas, las cuales no solo cambian según la zona horaria, sino

que también pueden presentar distintos formatos. Así pues, mientras en Estados Unidos

se utiliza el formato de 12 horas, en Europa y Asia se utiliza el formato de 24 horas

(Singh 2012, 136).

14

Respecto a las direcciones, no todas siguen el mismo orden, los códigos postales no

tienen la misma longitud en todos los países y algunos contienen tanto números como

letras; algunas culturas expresan la dirección con muy poca información y otras

proporcionan muchos datos (Singh 2012, 137).

Al igual que en las direcciones, la longitud también puede variar en el número de

teléfono, que además tendrá un prefijo diferente. Y respecto a las cifras, debemos tener

en cuenta que la separación numérica es diferente según el país, de tal forma que, como

bien se explica en el sitio web de Microsoft, mientras el separador decimal en español es

una coma (que debe situarse abajo y nunca arriba), en inglés es un punto. Sin embargo,

con el separador de millares se da la situación inversa: en español, el carácter que se

utiliza para separar los millares es el punto, mientras que en inglés es la coma. En otras

culturas como la sueca, esta separación se realiza mediante un espacio.

Además, es importante tener presente que el símbolo de la divisa en algunas ocasiones

va delante de la cifra –como es el caso del dólar- y en otras detrás (euro).

Por último, como también se menciona en este mismo sitio web, los números pueden

presentar diferentes formatos en función de la configuración regional, pues recordemos

que por ejemplo las culturas árabes no emplean los mismos números que se emplean en

Europa o América.

2) ORDENACIONES O ENUMERACIONES: Mientras que en idiomas como el

español o el inglés está establecido el orden alfabético, el World Wide Web Consortium

aclara que esto no es así en otros idiomas.

3) SISTEMAS DE MEDIDA: Hay que tener en cuenta que aunque la mayor parte de

países han adoptado el sistema métrico, otros países como Estados Unidos siguen usado

el sistema imperial (Singh 2015, 137).

4) ESTILO VERBAL: Como aspecto particularmente vinculado con la traducción, es

de sobra conocido que en función de a qué cultura nos dirijamos, deberemos optar por

un estilo verbal u otro. Además, también deberemos cuidar el tono o la terminología,

entre muchos otros aspectos (Singh 2012, 159-179).

5) TRADUCCIÓN: Deberemos llevar a cabo la traducción de todo aquello que se vaya

a mostrar en la interfaz y que por tanto vaya a visualizar el usuario meta.

6) ICONOS, SÍMBOLOS, SIGNOS Y COLORES: Los distintos iconos, signos,

colores y símbolos guardan una fuerte carga cultural que puede variar entre los distintos

usuarios meta según su cultura (Singh 2012, 160).

7) MÉTODOS DE PAGO: Roturier (2015, 178-179) considera fundamental cumplir

con las expectativas de los usuarios meta en todos los aspectos posibles:

15

“Another example of service adaptation that may be required to meet the expectations of local

users is related to the way local payments are made. While some credit card brands are very

popular in many countries, other forms of payment exist. When popular formats of payment are

unsupported, users are left frustrated and customers are lost. As an example, the publisher of the

Clash of Clans mobile game encountered an issue with Chinese users because it was soliciting in-

application payments through a specific market store application which was unsupported in China.

For this reason, it is now becoming customary for global business to support local payments

providers, such as allpago in Brazil or Alipay in China.

8) ASPECTOS LEGALES: La adaptación de documentos relacionados con

requerimientos legales, culturales, económicos, etc. específicos de cada país –como

puede ser la política de privacidad, los términos y condiciones de uso, etc.- también

forma parte del proceso de localización (Singh 2015, 150).

9) VÍDEOS: En aquellas ocasiones en las que haya vídeos en las páginas web o

aplicaciones, será necesario llevar a cabo la traducción de los mismos –ya sea a través

de la subtitulación en caso de que no tengan audio, del audio o incluso de ambos- para

que pueda afirmarse que dichas webs o aplicaciones están localizadas en su totalidad

(Roturier 2015).

10) FUNCIONALIDAD: No basta con que un producto de software o página web

muestre al usuario la información en su idioma materno, sino que también tiene que ser

capaz de reconocerlo y procesarlo si el usuario introduce información. Además, también

será necesario adaptar otro tipo de funcionalidades que se indicarán más adelante

(Roturier 2015, 179).

11) MANUAL DE AYUDA: cualquier aplicación de escritorio trae consigo un manual

de ayuda o uso. En la actualidad es cada vez más usual que estos manuales ya no

vengan impresos, sino que formen parte del propio programa constituyendo un apartado

específico. En cuanto a las páginas web o aplicaciones móviles, suelen contener también

un manual o un tutorial, ya sea un archivo de texto, uno o varios vídeos o una serie de

capturas de pantalla. Al igual que los elementos que forman parte de la interfaz, también

será necesario traducir este manual (Roturier, 2015).

12) CAPTURAS DE PANTALLA: En relación con lo anterior, Roturier (2015, 166)

también aclara que cada vez más aplicaciones incluyen en la sección de ayuda o en el

manual de uso numerosas capturas de pantalla que permiten al usuario entender el

funcionamiento de la aplicación o aprender a realizar una determinada tarea. Estas

capturas, evidentemente también deben adaptarse al público meta.

13) SELECCIÓN DE IDIOMA INTUITIVA: Es tremendamente importante que los

usuarios puedan detectar fácilmente dónde cambiar el idioma de una página web o

aplicación, de manera que el botón empleado para indicar esta selección deberá ser lo

más visible e intuitivo posible. Por otra parte, también se recomienda mantener el

nombre de los idiomas sin traducir, es decir, respetando el nombre del idioma tal y

como se escribe en el propio (Roturier, 2015).

16

7. ¿Cómo se realizan esas adaptaciones?

7.1. Prácticas fundamentales:

En relación con el apartado previo, ahora se presentan todas aquellas prácticas que

resultan recomendables -y en muchos casos fundamentales- para poder adaptar todos los

aspectos mencionados:

En primer lugar, resulta evidente que lo más recomendable es planear la localización en

el propio proceso de desarrollo del producto de software o página web para que se

pueda llevar a cabo un diseño y organización de dicho proceso en el que,

preferiblemente, y como bien indica Singh (2015), se determinarán los idiomas a los

que se desea traducir. El beneficio de esto consiste en poder predecir todos aquellos

requerimientos técnicos y lingüísticos que surgirán en función de las distintas lenguas

meta que se elijan.

A continuación, es fundamental identificar todos aquellos elementos localizables –en

ocasiones llamados elementos variables-, separarlos de las constantes y extraerlos en

archivos de recursos independientes. Esta práctica permitirá trabajar mejor con los

elementos localizables, que serán fácilmente identificables y consecuentemente el

proceso de localización será mucho más rápido, efectivo, sencillo y barato (Singh 2012,

132).

Uno de los elementos cuya extracción resulta especialmente importante son las cadenas

de texto. Esta labor de extracción resulta primordial para que el traductor pueda

centrarse de manera exclusiva en el contenido que debe traducir, ya que trabajar con una

pantalla abarrotada de código en el que hay que ir buscando las cadenas de texto puede

ser realmente abrumador y estresante. Por otra parte, dicha extracción evitara que se

rompa el código de manera accidental.

La extracción de las cadenas siempre será mucho más sencilla si estas no están lo que se

conoce como hard-coded, una práctica que Esselink (2000, 469) define de esta manera:

“a coding process that involves the embedding of translatable strings in the body of

programming code rather than in separate resource files.”

Tal y como se indica en el sitio web de Drupal –conocido software para la gestión de

contenido- el hardcoding es altamente desaconsejable para los propios desarrolladores,

quienes en caso de no evitar esta práctica deberán modificar el código fuente cada vez

que tengan que cambiar información que forme parte del contenido de la aplicación o

página web:

“Hardcoding is often attractive to coders who are in a hurry or are just learning. They see a way to

save a lot of time, and in the short run, they're right. The problem is that there are hidden costs to

hardcoding that can cost a lot of time.”

El beneficio de evitar esta práctica no solo es aplicable a las cadenas de texto, pues para

facilitar la adaptación se debe evitar que todo aspecto que va a requerir de la misma esté

17

incrustado en el código fuente. Entre dichos aspectos se incluyen también los elementos

visuales:

“The visible UI text (print, paste, copy, etc.), formatting styles (hyphenation, punctuation, text

delimiters, capitalization rules, line-wrapping rules, etc.), font sizes, names, and colors are all

examples of elements that should not be hard-coded, as formatting, text, and font requirements all

differ in different languages. For example, most English characters can be displayed on a 5 x 7

grid, but Japanese characters need at least a 16 x 16 grid to be clearly seen […].If the font size is

hard-coded for the requirements for one language, problems could develop in the future when the

website is developed for other languages that require a different font size; some characters might

be displayed too small to be legible.” (Singh 2012, 132).

En lo que concierne a seguir las distintas convenciones de las diferentes culturas meta

para indicar las fechas, horas, divisas, direcciones, etc. Singh (2012, 135) aconseja lo

siguiente:

“International Components for Unicode (ICU) and the Unicode Common Locale Data Repository

(CLDR) will both be of great help to software programmers and internationalization engineers in

determining various types of locale-formats. CLDR has an extensive standard repository of locale

data that is open source and can be easily accessed. ICU can help in formatting numbers, dates,

times and currency amounts according to the conventions of a chosen locale.”

Como bien se ha mencionado, las direcciones, por su parte, pueden variar enormemente

entre las distintas culturas. Por esto mismo, Singh también tiene una propuesta para

adaptarse con éxito a las distintas convenciones en este aspecto particular:

“Address formats are very different from locale to locale and should not be hard-coded. The best

approach is to have multiple fields for flat/apartment/building number, street, postal code, city,

country, etc. Moreover, postal codes vary in length and use both numbers and letters. Thus it is

prudent not to specify a particular format or length for such fields.”

Ha de decirse además que esta pauta es extensible a los números de teléfono.

Aunque parezca que con todo esto nos alejamos de la traducción, nada más lejos de la

realidad, pues según Singh (2012, 129):

“Even non-technical members of a web globalization team should understand the importance of

Unicode, CLDR, and ICU so that they can at least guide the software engineers to explore or follow

these conventions for successful web globalization efforts.”

En relación con esto, no solo es importante y extremadamente útil conocer la existencia

de estos recursos de Unicode, sino tener también una gran variedad de conocimientos

técnicos y comprender el funcionamiento de cada una de las fases del proceso de

localización con todo lo que ello implica.

Resulta fundamental mencionar que todos aquellos entornos en los que pueden aparecer

estos elementos que siguen distintas convenciones -como puede ser el caso de un

formulario- deberán permitir también la introducción, reconocimiento y procesamiento

de distintos tipos de caracteres propios de cada idioma. Para conseguir esto será

fundamental valerse de nuevo de Unicode:

18

“Multilingual computing is made possible by Unicode, the character-encoding industry standard

designed to allow text and symbols from various languages to be consistently represented and

manipulated by computers. Unicode allows users to process data and present user interfaces in

almost any language without having to switch from one encoding standard to another.” (Gillam,

2005).

No obstante, el procesamiento de texto no será la única funcionalidad que habrá que

adaptar. Roturier (2015, 165) es tajante a este respecto:

“While translating an application’s user interface may go a long way in competing with native

market applications, additional functionality adaptation may be required to win market share-. for

instance, a tax calculation application can have its user interface and associated documentation

content translated into multiple languages, but this is likely to be of limited value to target locale

users if this application is not adapted (or localized from a functional perspective) to support

multiple tax regimes”. […]

Centrándonos ahora en la labor concreta de traducción como parte del proceso de

localización, no solo es recomendable llevar a cabo la separación del código fuente de

aquellas cadenas de texto que vayan a someterse a traducción y extraerlas en archivos

aparte, sino que también resulta mucho más fácil para los traductores que se marquen de

manera previa todas aquellas cadenas de texto que no se deben traducir, ya que esto

evitará confusiones y errores (Singh 2012, 132).

Por otra parte, es del todo sabido que el contexto resulta vital para los traductores, lo

que choca con que, en comparación con otros ámbitos o especialidades de la traducción,

la localización de aplicaciones y páginas web se caracteriza especialmente por el poco

contexto con el que se trabaja. Por este mismo motivo, siempre será muy positivo que

los desarrolladores encargados de la internacionalización pongan a disposición de los

traductores el mayor número posible de recursos que puedan servirles de ayuda para

realizar su labor. Entre estos recursos se incluyen glosarios, comentarios, guías de estilo

o directrices en los que se hagan aclaraciones referidas al tratamiento de aspectos como

los placeholders, el tono, los atajos de teclado, la traducción de determinados términos,

la limitación de caracteres, etc.

Como parte cultural implicada en la traducción, también forma parte de la labor del

traductor adaptar el estilo verbal, pero para ello es necesario saber primeramente a qué

tipo de cultura va a ir dirigida la traducción. A este respecto, Edward T. Hall,

considerado por muchos padre de la comunicación intercultural, presentó en el año 1976

un modelo contextual en su obra Beyond Culture, donde hace una diferenciación entre

las que él mismo denomina culturas de contexto alto (high-context cultures) y culturas

de contexto bajo (low-context cultures):

Las culturas de contexto alto (CCA) son aquellas en las que sus miembros muestran

gran cercanía entre sí y cada individuo asume lo que el resto de individuos sabe. Por

este mismo motivo, la que la comunicación es primordialmente implícita, es decir, se

trata de una cultura en la que el contexto tiene más importancia que las palabras.

Elementos como las metáforas, los colores, imágenes, gestos, el tono de la voz, etc. son

19

fundamentales en la comunicación. Ejemplos de este tipo de cultura son: la mayor parte

de los países asiáticos, africanos y sudamericanos, y unos pocos países europeos (Singh

2012, 169-175).

En cuanto a las culturas de bajo contexto, como su propio nombre permite adivinar, son

culturas que basan su comunicación en el lenguaje verbal por encima del contexto. La

información se expresa de manera más explícita y directa, de forma que se intentan

eludir las ambigüedades. Estados Unidos, Francia, Alemania, Reino Unido, los países

escandinavos o Australia son ejemplos de este tipo de cultura (Singh 2012, 169-175).

Así pues, a la hora de llevar a cabo la traducción de un producto de software o página

web, el estilo verbal empleado será necesariamente distinto en función del tipo de

cultura al que nos estemos dirigiendo, de forma que si por ejemplo la cultura meta se

corresponde con una cultura de contexto alto, el tono y estilo deberán ser más

elaborados, formales y floridos. Singh (2012, 173) aclara:

“The writing style should emphasize a general sense of politeness. For example, Japanese websites

depict politeness in the form of customary notes of thanks to the customers, greetings to the

customers, and notes of best wishes for hood health, which are not commonly seen in the websites

of low-context cultures.”

Por el contrario, si la cultura meta es una cultura de contexto bajo, deberemos ser

mucho más claros y directos. Para ello podremos valernos de recursos como los

superlativos, el estilo impersonal o la forma pasiva (Singh 2012, 173).

Otros aspectos estrechamente relacionados con la traducción son la limitación de

espacio o la dirección de escritura del idioma, ya que hay idiomas como el árabe o el

hebreo que se escriben de derecha a izquierda. A este respecto Singh (2012, 134) tiene

también algo que comentar:

“The program being used should provide RTL (Right to Left) support to address this issue.

Engineers are advised to take this into consideration when developing websites for languages such

as Arabic and Hebrew. HTML and CSS are designed to work with RTL languages.”

La distinta dirección de escritura en función del idioma, junto con el hecho de que en

algunas ocasiones se combinan en un mismo texto dos idiomas con direcciones de

escritura diferentes, y sumado también al aspecto referente a las distintas convenciones

en los formatos de direcciones, fechas, etc. hacen fundamental que se emplee la

codificación Unicode en las distintas aplicaciones o sitios webs que se desarrollen:

“The Unicode Bidirectional Algorithm, often abbreviated to just "UBA", explains in detail how

text should be laid out in lines whenever it consists of a mixture of left-to-right script characters

and right-to-left script characters. […] The UBA depends on a character property called

20

Bidi_Class, which has property values defined for all Unicode characters. Note that in addition to

left-to-right characters (for example, in the Latin script) and right-to-left characters (for example,

in the Arabic script), there are also many characters with a neutral direction. Their behavior in

bidirectional text layout depends on the details of their proximity to other characters of strong

right-to-left or left-to-right direction. For example, most punctuation and symbol characters have

neutral direction.” (Unicode.org).

En cuanto a la limitación de espacio mencionada, es importante que los desarrolladores

tengan en cuenta que al traducir el texto original se puede producir una expansión o

reducción del mismo en lo que a longitud se refiere.

A continuación se muestra una tabla que recoge los porcentajes en los que se incrementa

o reduce la longitud del texto en función del idioma meta y siendo el inglés la lengua de

origen:

21

Roturier (2015, 89) considera que la mejor manera de evitar un problema de espacio que

pueda resultar en frases cortadas o truncamientos no deseados y que por lo general se

detecta al realizar el QA es “to use a responsive format that does not use fixed

dimensions in the source”. Por otra parte, Singh (2012) aconseja predecir las posibles

contracciones o expansiones a través de la utilización de herramientas específicas. Una

herramienta muy útil para esta práctica es Xcode, pues como indican Buttfield-Addison

et alii. (2016) “it lets you test your application in a fake language that simply repeats

every piece of text twice. […] If every piece of text in your app is doubled, you can see

how your interface might need to adjust to account for wider-than-expected text.”

Pasando a los iconos, gráficos, símbolos y signos, al igual que las imágenes, siempre

será mucho más fácil adaptarlos a un determinado público meta si estos no tienen texto

incrustado:

“Costs increase if text is embedded in graphics, as it is more difficult to extract the text when

translation is needed in order to use the same graphic for other locales. Creating a whole new set of

graphics for each country may be required”. (Singh 2012, 132).

Singh (2012) además incide en que todos estos elementos, junto con los colores,

contienen una gran carga cultural, por lo que habrá que tener especial cuidado en su

elección. Así pues, en determinadas circunstancias y en función de si se trata de una

cultura de alto contexto o de bajo contexto, estos elementos deberán modificarse para

que cumplan con las expectativas de los usuarios meta y no se produzcan

malinterpretaciones. Por esto mismo es importante intentar evitar símbolos que puedan

contener carga política o que representen armas, violencia, contenido sexual, etc.

Este mismo autor recoge en su libro (2012, 161) un ejemplo que ilustra la importancia

de esto:

“Customers in the United Kingdom found the trash can icon in the Apple Macintosh “Trash can”

very confusing, because it was a cylindrical bin, shaped exactly like mailboxes in Britain. In this

case it was particularly difficult, because mail was mistakenly being sent to the trash can”.

Si nos centramos ahora en los mencionados colores, estos tienen un gran valor

simbólico que varía según la cultura, por lo que a la hora de localizar un producto,

también deberemos sopesar si mantener los colores iniciales o cambiarlos para evitar

posibles connotaciones negativas. Es precisamente por este motivo por el que, como

bien hemos señalado antes, no se aconseja que los colores estén incrustados en el código

fuente. Yunker (2003) pone un ejemplo de esto y afirma que mientras el color rojo se

relaciona con el sexo, lo picante, la excitación o la pasión en Estados Unidos, en India

guarda relación con el nacimiento y la fertilidad y en China, por su parte, evoca

comunismo, celebración, buena suerte y alegría.

Como bien hemos dicho, cada vez es más frecuente que en los manuales de ayuda o

guías de usuario aparezcan capturas de pantalla que ayuden al usuario a entender el

manejo de una determinada aplicación o a realizar una tarea concreta con la misma. La

adaptación de estas capturas de pantalla puede ser una tarea realmente complicada, pues

no solo es importante que estén en el idioma del usuario que está interactuando con la

22

aplicación, sino que también es altamente recomendable que dichas capturas estén

actualizadas y se correspondan con la versión correspondiente de la aplicación, pues al

fin y al cabo sirven de guía visual a los usuarios (Roturier 2015, 166).

7.2. Otras pautas:

- Evitar utilizar la misma variable en el código fuente para distintas cosas y dar a las

mismas un nombre significativo que permita intuir para qué sirven. (Roturier, 2015)

- Esselink (2000, 68) define los placeholders como “characters that are usually preceded

by a percentage (%) sign and replaced by another word, value or string at application

run-time.” A este respecto, es importante aportar comentarios para el tratamiento de los

mismos o intentar que sean intuitivos, siempre y cuando no se pueda o quiera evitar su

uso (Singh, 2012).

-Evitar la concatenación de las cadenas de texto. Singh (2012, 134) define la

concatenación como “binding two strings together to form a new string” y asegura que

puede resultar un gran problema en caso de que se aplique a una cadena de texto que se

va a localizar ya que “the languages use different sentence structure, and thus the order

of words changes from language to language”.

- En relación con la selección del idioma, no solo es fundamental proporcionar un

método de selección que resulte intuitivo y fácil de encontrar para el usuario, sino que

además se recomienda evitar la utilización de banderas para representar el idioma en el

menú o pantalla donde el usuario puede seleccionar el lenguaje en el que desea que se

muestre la web o aplicación. Por otra parte, como ya se ha comentado, es aconsejable

mantener el nombre de los idiomas en el idioma correspondiente. Si esto no se lleva a

cabo, puede darse la situación en la que nos equivoquemos en la elección y

seleccionemos un idioma que desconocemos por completo. Encontrar el lugar donde

seleccionar un idioma diferente puede ser tremendamente complicado si todo está en un

código completamente desconocido para nosotros y si además el botón empleado para

cambiar el idioma consiste en un texto y no en un icono significativo. (Roturier, 2015).

- En lo referido al mencionado aspecto de evitar la utilización de banderas, esto se

explica porque, si por ejemplo se emplea la bandera de Estados Unidos para representar

el inglés, otras culturas angloparlantes como la australiana o la británica se pueden

sentir excluidas y ofendidas. (Singh, 2012).

- Es importante no olvidar la importancia de adaptar también las descripciones

mostradas en el App Store o en el Google Play Store, pues es gracias a dichas

descripciones por las que normalmente un usuario elige instalar una determinada

aplicación en lugar de otra. Si el usuario se encuentra con la descripción en un idioma

que no comprende o del que no tiene buen dominio, es bastante probable que descarte

de manera automática instalar es aplicación y pase a buscar otra.

23

- Algo que también beneficia a los traductores es la utilización de formatos que faciliten

su labor, es decir, formatos compatibles con herramientas altamente empleadas como el

sistema de gestión de traducción Trados o MemoQ.

- Por último, en lo que respecta a la totalidad del proceso, es bastante importante

mantener la uniformidad y la coherencia: resulta evidente que si los encargados de la

internacionalización evitan que el texto que requiere traducción esté incrustado en el

código fuente, deberán aplicar este mismo procedimiento al resto de aspectos

nombrados (fuente, formato, colores, etc.). Es decir, no resulta lógico que si el motivo

de evitar que ciertos aspectos estén incrustados en el código es facilitar la labor de

traducción, esta práctica tan solo se aplique a un aspecto concreto y no a todos los

posibles.

En relación con la uniformidad, Singh (2012, 133) también cree, de manera bastante

oportuna a mi parecer, que debe existir coherencia en el nombre dado a los

identificadores de los distintos recursos o en la forma que se utilice para añadir

información de utilidad (ej.: comentarios). Considero que este aspecto resulta

destacadamente importante, pues no son escasas las situaciones en las que los

traductores se ven obligados a intentar adivinar qué ha querido indicar el desarrollador

con un determinado símbolo o referencia. No obstante, hablaremos más detalladamente

de este aspecto en el estudio.

8. Internacionalización:

8.1. ¿En qué consiste la internacionalización?

El cumplimiento de todas estas pautas que allanan el terreno a la localización es lo que

recibe el nombre de internacionalización, abreviada como i18n y definida por Esselink

(2003) de la siguiente manera:

“Internationalization refers to the adaptation of products to support or enable localization for

international markets. Key features of internationalization have always been the support of

international natural language character sets, separation of locale-specific features such as

translatable strings from the software code base and the addition of functionality or features

specific to foreign markets. Without internationalization, localizing a product can be very

challenging.”

En definitiva, estamos ante un proceso que idealmente tiene lugar en la fase inicial del

desarrollo y cuyo objetivo es preparar las páginas web y aplicaciones desde el punto de

vista técnico para que se pueda llevar a cabo la localización:

“Internationalization (i18n) ensures that […] the back-end processes have a flexible architecture to

operate without any problem with external modules […]. Internationalization should not be seen as

an afterthought; if it is, the process can become very expensive.” (Singh 2012, 130).

24

8.2 ¿Qué pasa si no se internacionaliza?

Si se omite la labor de internacionalización o esta se realiza una vez desarrollada la

aplicación, la localización puede suponer un reto enorme. Esto no quiere decir que se

convierta en una labor totalmente imposible, pues por ejemplo, para extraer las cadenas

de texto traducibles siempre podremos recurrir a expresiones regulares. No obstante,

esta práctica seguramente suponga una gran inversión de tiempo y tenga como resultado

que se extraigan también cadenas de texto que no requieren traducción o que se rompa

el código (Roturier, 2015).

Por su parte, Singh (2012, 130) asegura que en numerosas ocasiones este proceso se

realiza pero sin éxito:

“Localization vendors complain that companies often come to them once they have put half-

hearted efforts into internationalization or have run into problems. Correcting past mistakes in

internationalization can be time-consuming, laborious, and expensive”.

Dunne (2006, 6) se suma también a los autores que ven la internacionalización como un

paso previo fundamental para poder llevar a cabo la localización: “The relative success

of translation and localization efforts depends to a great extent on the successful

implementation of internationalization strategies.”

8.3. ¿Por qué no siempre se internacionaliza antes de localizar?

Hasta ahora parece haber quedado claro que la internacionalización es un proceso

complementario a la localización sin el cual esta labor se vuelve tremendamente

complicada. Por este mismo motivo, parece razonable y hasta evidente que todas

aquellas empresas que deseen localizar un producto siempre lo someterán a un proceso

de internacionalización previo. Sin embargo, la realidad, tal y como asegura Singh

(2012, 123-124) no siempre es esta:

“Many companies, acting either in haste or with insufficient resources or knowledge, ignore this

important back-end process and either develop separate templates for different countries or just use

machine-translated versions of the parent home page. Idiom Technologies conducted a global

quotient survey and found that 36 percent of e-business executives interviewed had done nothing

to prepare their website’s back-end processes to meet the needs of international users, while an additional third had adjusted only a minority of their site capabilities.”

En relación con esto, es importante que seamos conscientes que las empresas de

desarrollo de software existentes no se limitan a grandes corporaciones como Microsoft,

IBM o Apple. Estas compañías constituyen una excepción, pues lo más común es que

las otras cientos de miles de empresas de desarrollo de software cuenten con recursos

muchísimo más limitados. Por este motivo, como bien indica Roturier (2015), muchas

toman la decisión de lanzar al mercado una determinada aplicación en un único idioma

–y obviamente sin internacionalizar- y esperan a ver el efecto que tiene en el mercado

25

objetivo antes de abarcar un mayor número de mercados. Así pues, las empresas de

desarrollo de software a veces prefieren correr el riesgo de incurrir en mayores costes

futuros en caso de que internacionalicen la aplicación más adelante, antes que

enfrentarse a la menor posibilidad de perder una gran cantidad de dinero si se da la

situación en la que una aplicación internacionalizada y adaptada a varios mercados

fracase en los mismos. Además, también puede darse el caso totalmente opuesto: existe

la posibilidad de que, por los fenómenos del mercado y de manera inesperada, una

aplicación triunfe enormemente. En dicha situación, afirma este mismo autor, “the

infrastructure supporting a service may not be ready to accommodate thousands or

millions of users so it may be preferable to restrict access by not supporting certain

languages” (Roturier 2015, 186).

9. ¿Qué es necesario para ser un buen localizador?

Una vez llegados a este punto del proyecto, resulta oportuno hacer una recopilación de

todas aquellas competencias que idealmente deberá poseer un buen localizador en

función de todo lo que hasta aquí hemos visto. No obstante, primero considero

necesario aclarar quiénes forman parte del equipo de localización:

“Members of the localization team may include translators, linguists, graphic designers, e-

commerce professionals, cultural consultants, international business professionals, and legal

advisors to ensure compliance with global e-commerce regulations. The team should include the

project manager and project coordinators responsible for the coordination of tasks between the

internationalization team and the localization team, or even with various other departments or

country units. The team should work closely with internationalization engineers to ensure the

proper handling and localization of databases and tools, the proper implementation of localization

guidelines, and adequate testing.” (Singh 2015, 196).

Como bien hemos dicho, la traducción tan solo supone la punta del iceberg dentro del

proceso de localización, lo que implica que el traductor no tiene por qué ver su labor

reducida al aspecto lingüístico, sino que, tal y como afirma Sandrini (2008) la

localización constituye una gran fuente de oportunidades para estos profesionales:

“Localization can be a great opportunity for translators if they have the ambition to go beyond

translation, to acquire the necessary skills and to take responsibility for the whole process. If not,

or if translators insist on doing only text translation without taking into account the larger picture,

their role will be reduced to mere free-lance contributors for localization professionals.”

Así pues, me atrevería a decir que la localización es una de las especialidades de la

traducción en la que más conocimientos se requieren y mayor número de prácticas se

ven implicadas:

En primer lugar, y como ya hemos mencionado, resulta fundamental un buen manejo y

conocimiento de la tecnología, lo que resultará más fácil si existe cierta pasión por la

misma. La razón de esta afirmación reside en que siempre será más sencillo aprender el

manejo de nuevas herramientas o mantenerse al día de todas aquellas novedades y

actualizaciones que se produzcan dentro del propio sector de la localización o en

26

sectores afines -como puede ser el de la informática-, si existe un interés destacado por

este tipo de conocimientos.

En relación con esto, considero también fundamental que el localizador tenga un amplio

conocimiento y manejo de distintos formatos de archivos, o que al menos disponga de

facilidad para familiarizarse con los mismos, pues no todos los clientes tienen

preferencia por el mismo formato.

Respecto a labor de traducción, es importante saber que la temática de las aplicaciones o

páginas web que se traducen puede ser increíblemente variada, de forma que, para poder

realizar dicha traducción, no bastará con tener un gran manejo de la tecnología, sino que

se requerirá dominio en ciertas especialidades (traducción económica, traducción

jurídica, científico-técnica, biosanitaria, literaria, etc.) al igual que en cualquier otro

encargo de traducción.

En esta misma línea, al igual que en cualquier encargo de traducción, será necesario

saber quién es el receptor de la misma, pues en función de este aspecto el traductor

deberá tomar una serie de decisiones. Por ejemplo, en caso de que el encargo consista

en la localización de una aplicación móvil destinada únicamente a mujeres, es probable

–y recomendable- que el traductor dé especial importancia a la utilización de un

lenguaje no sexista, mientras que si por ejemplo el encargo consiste en una aplicación

bancaria, se dará prioridad a otro tipo de aspectos. Esta adaptación al tipo de encargo se

requiere como resultado de la irrompible relación que existe entre los idiomas y la

cultura.

Por otra parte, se puede dar el caso de que el encargo implique también tareas de

traducción audiovisual, pues como se ha comentado, en algunas ocasiones las páginas

webs o aplicaciones contienen vídeos que o bien forman parte de las mismas o bien

actúan como tutorial. En caso de haber vídeos, es posible que sea necesario realizar

labores de subtitulación, de ajuste de guion y doblaje, de transcreación, o incluso de

audiodescripción.

Por último, vivimos en un mundo plagado de aplicaciones y páginas web donde la

competitividad cada vez es mayor. Por este mismo motivo, es posible que en algunas

ocasiones se demanden conocimientos de SEO (Search Engine Optimization) en el caso

de las páginas web y técnicas ASO (App Store Optimization) para las aplicaciones

móviles. Roturier (2015, 173) define el SEO de la siguiente manera:

“SEO means trying to match the popular keywords users rely on to search for content using a

search engine with the words that should be present in the content that publishers want to see

accessed by users. […] It can help publishers promote content which would otherwise have been

translated and published but possibly not found by users”.

En resumen, el SEO, conocido en español como «posicionamiento web» se emplea con

el objetivo de mejorar el posicionamiento de una determinada página web en los

resultados proporcionados por los motores de búsqueda.

27

En cuanto al ASO, podría decirse que es el SEO de las aplicaciones móviles, pues

consiste en mejorar el posicionamiento de las mismas, aunque en este caso en el Google

Play Store y en el App Store. (AA.VV, s.d).

En definitiva, a pesar de que a menudo se produce una adjudicación de las distintas

tareas en función del manejo de cada traductor en el ámbito concreto al que se adscriben

las mismas, considero que siempre será más fácil que demanden los servicios de un

profesional inquieto por naturaleza si, como bien afirmaba Sandrini previamente, este

no limita su conocimiento ni área de actividad. De esta forma, creo bastante necesario

que el localizador sea una persona de mente abierta, que trate de adaptarse fácilmente a

las novedades y demandas de un sector en constante cambio, que preferentemente tenga

cierta pasión por la tecnología, y que por supuesto posea un gran manejo de la semiótica

y un amplio conocimiento cultural para poder adaptarse al tipo de encargo y saber tratar

algunos de los aspectos mencionados (elección del estilo verbal, colores, símbolos…)

con el mejor resultado posible.

10. Básicos de programación:

Antes de pasar a la segunda parte del trabajo, se va a llevar a cabo una breve

presentación y explicación de una serie de conceptos básicos de programación cuyo

conocimiento por parte del traductor puede resultar realmente interesante.

10.1. Introducción:

Como bien se ha transmitido hasta ahora, la programación constituye un ámbito

adyacente a la localización. Por esto mismo, puede resultar conveniente que el traductor

posea ciertos conocimientos básicos de programación que no solo le permitirán tener un

mejor entendimiento de la labor de aquellos profesionales encargados de realizar la fase

previa y fundamental para poder llevar a cabo la localización, sino que además le

proporcionarán una visión más amplia del proyecto de creación de aplicaciones o

páginas web desde que estas son una simple idea, hasta que se materializan y son

accesibles para los usuarios finales.

10.2. ¿Qué es un lenguaje de programación?:

En primer lugar, es fundamental saber qué es exactamente un lenguaje de programación.

Villena (2017) define este concepto de manera la manera más sencilla posible:

«Es un lenguaje formal diseñado para expresar los procesos que debe ejecutar la máquina. […]

Cada lenguaje de programación tiene su propia sintaxis y su propio vocabulario».

Así pues, aclara este programador, si queremos mostrar un mensaje en pantalla al

usuario, mientras que en Python basta con poner print y escribir el mensaje entre

comillas inglesas, en Java esto es algo más complejo, pues es necesario poner

28

System.out.println (“mensaje”) y siempre respetando las mayúsculas y minúsculas. De

esta manera, para conseguir lo mismo, el código necesario será más largo o más corto

en función del lenguaje de programación.

Figura xxx: Mostrar un mensaje en pantalla con Python.

Figura xxx: Mostrar un mensaje en pantalla con Java.

Villena también nos explica que para que la máquina entienda lo que hemos escrito con

el código de programación, se «traduce» lo escrito a un lenguaje que el procesador

pueda comprender. Esto se consigue de dos maneras: mediante la compilación o a través

de la interpretación.

En relación con esto, podemos hacer una diferenciación entre lenguajes de

programación compilados y lenguajes de programación interpretados.

10.3. Lenguajes compilados y lenguajes interpretados:

- Lenguajes compilados: Una vez más, Villena (2017) nos da una sencilla definición

que nos permita entender que los lenguajes compilados son «aquellos en los que se

traduce todo el código fuente al lenguaje de la máquina creando un archivo ejecutable

que se usará para hacer funcionar el programa».

- Lenguajes interpretados: En cuanto a los lenguajes interpretados, este mismo

programador explica que la diferencia con los anteriores es que en los interpretados, las

instrucciones se traducen al lenguaje de la máquina pero no de golpe, sino una por una;

una vez se traduce la primera instrucción, esta se ejecuta y se pasa a traducir la segunda

instrucción, que también se ejecuta para pasar a traducir la tercera instrucción, etc.

29

Fuente: Fundamentos de la programación. Curso online (Udemy).

10.4. Diferencia entre los lenguajes de programación y los lenguajes de marcado:

A menudo se piensa que todos los lenguajes informáticos son lenguajes de

programación. De hecho, HTML muchas veces se define como un lenguaje de

programación, cuando en realidad es un lenguaje de etiquetado que sirve para

estructurar el contenido de las páginas web. Los lenguajes de etiquetado no manejan

datos ni necesitan seguir una serie de instrucciones de manera ordenada para realizar

una determinada acción como sí hacen los lenguajes de programación. (Villena, 2017).

Así pues, HTML es un lenguaje de etiquetado o marcado que, tal y como define Álvarez

et alii (2016, 6) en su manual de HTML, se emplea «para especificar el contenido que

los navegadores deben representar a la hora de mostrar una página web». En definitiva,

HTML tiene como fin «dar significado al texto (también conocido como semántica)

para que el navegador sepa cómo mostrarlo correctamente». (González Collado, 2018).

Por otra parte, XML a menudo se cataloga de forma equivocada como un lenguaje de

marcado o etiquetado, cuando en realidad, tal y como Reino Romero nos indica en su

manual de XML, es «un metalenguaje que nos permite definir lenguajes de marcado

30

adecuados a usos determinados». En definitiva, la finalidad fundamental de XML es

«representar información estructurada en la web, de modo que esta información pueda

ser almacenada, transmitida, procesada, visualizada e impresa, por diversos tipos de

aplicaciones y dispositivos». (AA.VV, s.d).

Por último, en línea con la estructuración de páginas web, CSS tiene una estrecha

relación con HTML, de manera que como se explica en el apartado que W3Schools

dedica al mismo:

“CSS stands for Cascading Style Sheets. It describes how HTML elements are to be displayed on

screen, paper, or in other media and it saves a lot of work. It can control the layout of multiple web

pages all at once; external stylesheets are stored in CSS files”.

10.5. Lenguajes de programación más empleados y áreas de utilización:

Villena (2017) diferencia cuatro áreas principales en función de lo que se va a

programar: desarrollo web, desarrollo de aplicaciones de escritorio, desarrollo de

videojuegos y desarrollo de aplicaciones móviles. No obstante, también afirma que

existen más áreas algo menos conocidas como la programación de bases de datos o la

programación para análisis de datos.

Además nos aclara que, frente a la creencia bastante extendida de que hay lenguajes que

son muy potentes en todas las áreas y a pesar de que efectivamente la utilización de un

mismo lenguaje casi nunca se limita a un único ámbito, en realidad los lenguajes de

programación se crean para ser especialmente potentes en un área en concreto y cumplir

con una serie de necesidades o mejorar una serie de aspectos observados previamente en

la misma. Por este mismo motivo, siempre habrá uno o varios lenguajes más adecuados

en función de lo que se vaya a desarrollar. No obstante, también es importante decir que

en los proyectos se suelen combinar varios lenguajes.

Por otra parte, según el Índice TIOBE, a fecha de noviembre de 2017, estos eran los

diez lenguajes de programación más demandados:

31

Como es evidente, entendemos que esta clasificación varía no solo en función del

momento en el que se elabore, sino también en función de quien se encargue de

elaborarlo. Por ejemplo, Github también realiza este tipo de estadísticas.

En línea con lo anterior, dentro de la localización podremos diferenciar tantas áreas de

especialidad como áreas de programación existen, de forma que mientras que algunos

traductores se dedican de forma exclusiva a localización de videojuegos, de páginas

web, de aplicaciones móviles o de aplicaciones de escritorio, otros seguramente reciban

y acepten encargos adscritos a distintas áreas. Por eso mismo, creemos importante

conocer las principales áreas en las que se emplea cada uno de los lenguajes de

programación que se sitúan en las diez primeras posiciones dentro del mencionado

índice TIOBE.

A continuación se resumen las principales áreas en las que se utilizan los diez lenguajes

recogidos en la tabla. No obstante, esta clasificación realizada a partir del curso online

Fundamentos de programación que Javier Villena imparte en la plataforma Udemy, no

pretende ser de carácter restrictivo, sino simplemente transmitir una idea global:

1) Java: Se emplea para mundo web, aplicaciones móviles, videojuegos y

aplicaciones de escritorio. Por ejemplo, todas las aplicaciones para Android se

pueden hacer con Java.

2) C: Las principales áreas para las que se utiliza este lenguaje de programación

son el mundo web, sistemas, aplicaciones de escritorio y videojuegos. Ejemplo:

todos los sistemas operativos Unix están hechos con C.

32

3) C++: Se usa para aplicaciones móviles, mundo web, sistemas, aplicaciones de

escritorio, videojuegos y análisis de datos. Ej.: Firefox, Chrome o Adobe están

hechos con C++.

4) C#: Videojuegos, aplicaciones móviles, aplicaciones de escritorio y mundo web.

Por ejemplo, Paint.net está hecho con este lenguaje.

5) Python: Mundo web, sistemas, análisis de datos y videojuegos. Esto no es

estrictamente cerrado, pues por ejemplo YouTube, Instagram o Spotify funcionan

con Python.

6) PHP: Se utiliza de forma exclusiva para el desarrollo web. Por ejemplo,

Facebook y Wikipedia están hechos con PHP.

7) JavaScript: Se utiliza fundamentalmente en para el mundo web y videojuegos.

PayPal está hecho con JavaScript.

8) Visual Basic. NET: este lenguaje de programación pertenece a Microsoft,

compañía que lo describe como un lenguaje para crear aplicaciones móviles, de

escritorio y páginas web. Sin embargo, basta con hacer una breve consulta en

Internet para leer gran cantidad de opiniones de programadores que consideran que

a día de hoy este lenguaje apenas se emplea más que como herramienta didáctica a

modo de lenguaje introductorio.

9) Perl: Se utiliza fundamentalmente para análisis de datos y el mundo web. No

obstante, originalmente se creó para la manipulación de textos.

10) Ruby: Principalmente para el mundo web y videojuegos. Ej.: Twitter o

SlideShare están hechos con Ruby.

Aunque como bien hemos dicho, esta clasificación no pretende excluyente, es cierto que

los lenguajes que generalmente se emplean para el desarrollo web son interpretados,

mientras que aquellos que normalmente se emplean para el desarrollo de aplicaciones

móviles y aplicaciones de escritorio suelen ser compilados. Esto no es casual, pues,

como ya se ha explicado, los lenguajes compilados generan un ejecutable que es

necesario descargar si por ejemplo queremos contar con una determinada aplicación en

nuestro teléfono móvil o en nuestro ordenador. Es por esto mismo por lo que, dada la

inmediatez que caracteriza Internet, se emplean lenguajes interpretados, ya que si se

empleasen lenguajes compilados para el desarrollo de páginas web sería necesario

descargar un ejecutable cada vez que quisiéramos navegar en cualquier sitio web.

10.6. Variables, lenguajes tipados y lenguajes no tipados:

Como bien se ha comentado en el apartado destinado a las prácticas recomendables de

internacionalización, es aconsejable que los programadores den nombres significativos a

las variables, de manera que se pueda intuir a partir de los mismos para qué sirve esa

variable. No obstante, antes de poder juzgar si el nombre de las variables resulta

33

intuitivo o no, es necesario saber qué es exactamente una variable. Villena (2017) la

define de la siguiente manera:

«Una variable es una zona de la memoria de un dispositivo en la que se almacena un dato. Es la

forma más básica que existe de almacenar de información, y en función de los datos que queramos

que almacene la variable (números, caracteres, cadenas de texto, etc.) esta será de un tipo o de otro

y necesitará más o menos memoria».

No obstante, no siempre será necesario declarar de qué tipo es la variable, motivo por el

que existe una diferenciación entre los lenguajes tipados, y aquellos que reciben el

nombre de no tipados.

Como Villena (2017) nos explica una vez más de forma muy clara, los lenguajes tipados

son aquellos en los que es necesario decir de qué tipo va a ser la variable, la cual solo va

a permitir almacenar información que se corresponda con ese tipo. Por ejemplo, si en

Java declaramos una variable de tipo int –para almacenar números enteros-, no

podremos guardar en la misma una cadena de texto. En caso de que lo intentemos nos

saltará un error, pues única y exclusivamente podemos guardar datos que se

correspondan con el tipo de la variable que hemos declarado.

Por el contrario, los lenguajes no tipados pueden guardar cualquier tipo de dato en

cualquier variable. Es decir, es posible reservar una zona de memoria y meter en la

misma tanto un número como una cadena de texto o un carácter. A estos lenguajes

también se les conoce como lenguajes tipados dinámicos, pues se reconoce de manera

dinámica qué tipo de dato se está guardando y cuánta memoria hace falta. No obstante,

existe cierta polémica en cuanto a la terminología.

Una vez más, este programador y analista nos aclara que el hecho de que los lenguajes

tipados y no tipados se correspondan con los compilados e interpretados

respectivamente no se trata de una simple coincidencia, pues recordemos que los

compilados van a producir un archivo ejecutable, pero para ello primero será necesario

saber cuánta memoria hace falta. Por esto mismo habrá que decir necesariamente de qué

tipo será cada variable.

En cuanto a los lenguajes interpretados, dado que las instrucciones se van traduciendo al

lenguaje de la máquina y ejecutando una a una, la memoria se va reservado en el acto y

por tanto no es necesario saber de antemano cuánta va a hacer falta.

Por último, con respecto al nombre de las variables, es importante saber que siempre

deberemos dar un nombre a la zona de la memoria que se está reservando para poder

administrarla. Este nombre se coloca justo después del tipo de dato que va a almacenar

la variable –en el caso de los lenguajes tipados- y sirve como identificador de la misma.

Así, si por ejemplo queremos crear una variable en Java donde guardar la edad de una

persona de 21 años, deberemos escribir lo siguiente:

int edad = 21;

34

Como bien hemos explicado, int se corresponde con el tipo de la variable, que va a

almacenar un número entero. En cuanto a «edad», este será el nombre que estamos

dando a esa zona de la memoria y del que tanto venimos hablando a lo largo de todo

este proyecto de investigación. Por último, con el operador “=” le asignamos un valor a

la variable.

Además, existen una serie de restricciones con respecto al nombre de la variable. Estas

restricciones para la mayoría de los lenguajes de programación son:

- No puede ser una palabra reservada del lenguaje (if, while, for…).

- No puede empezar con un número aunque sí contenerlo.

- No puede tener espacios.

- Empieza por una letra o un guion bajo (_). (AA.VV, s.d)

Como parte destacadamente importante de este apartado, hemos elaborado una tabla que

recopila toda la información vista hasta ahora sobre los distintos lenguajes de

programación y que además incluye un apartado dedicado a la sintaxis de los

comentarios –tanto de una sola línea como multilínea- correspondiente a cada lenguaje.

Con esta tabla se pretende dar al traductor una herramienta con información muy básica

pero que puede resultar tremendamente útil en caso de querer dedicarse a la localización

sin acotar la vista simplemente en la traducción.

35

LENGUAJE

COMPILADO/

INTERPRETADO

TIPADO/ NO

TIPADO

SINTAXIS DE

COMENTARIOS

Java

Compilado

Tipado //

/* */

C

Compilado

Tipado //

/* */

C++

Compilado

Tipado //

/* */

C#

Compilado

Tipado //

/* */

Python

Interpretado

No tipado

#

PHP

Interpretado Php 7 tipado

Php <7 No tipado

//

/* */

JavaScript

Interpretado

No tipado //

/* */

Visual Basic.NET

Interpretado

No tipado

'

Perl

Interpretado

No tipado

#

Ruby

Interpretado

No tipado

#

Una vez adquiridos ciertos conocimientos básicos para el entendimiento de algunos de

los aspectos analizados en el estudio que constituye la parte fundamental del presente

trabajo de investigación, pasamos a presentar dicho estudio:

36

11. Estudio:

11.1. Introducción:

Como bien se ha descrito al comienzo de este trabajo de investigación, parte del mismo

consiste en un estudio en el que se van a analizar varias aplicaciones y páginas web. En

concreto dos páginas web, dos aplicaciones móviles y dos aplicaciones de escritorio.

Como también se ha comentado en el resumen del proyecto, casi todos ellos son de

código abierto, un hecho que no es casual.

La decisión de centrarme en proyectos de código abierto viene motivada por dos

razones principales que guardan relación entre sí.: La primera de las razones de esta

elección atiende al hermetismo y confidencialidad que caracterizan a las empresas

dedicadas al desarrollo de software y creación de páginas web, hecho por el que he

obtenido numerosas negativas a la hora de intentar conseguir el código de cualquier

aplicación o web que no fuese de código abierto. No obstante, este factor, en lugar de

frenarme o suponer una limitación para la elaboración del presente trabajo, me ha

proporcionado una perspectiva diferente y brindado la oportunidad de conocer más a

fondo tanto la cada vez más frecuente práctica que recibe el nombre de crowdsourcing,

como las crecientes plataformas de desarrollo colaborativo como Github o Bitbucket -

donde se alojan infinidad de proyectos a los que cualquier persona puede acceder- y las

plataformas de traducción en línea (ej.: Transifex o Gitlocalize) que dichas plataformas

de desarrollo colaborativo ponen a disposición de cualquier usuario que desee colaborar

en la traducción de estos proyectos –lo que en sí constituye un ejemplo de

crowdsourcing-.

En lo referido al material, para la realización de este estudio se han empleado por una

parte Android Studio y Visual Studio Code para la visualización y manipulación de los

recursos que constituyen los distintos proyectos examinados, y por otra parte el

programa Lightshot que nos ha permitido hacer las capturas de pantalla.

En cuanto a las aplicaciones y páginas web, todas ellas, a excepción de la aplicación

para móvil «Pamplona Negra», se han obtenido y descargado desde Github; a pesar de

que la aplicación móvil que constituye una excepción no es de código abierto, uno de

sus desarrolladores nos la ha proporcionado con fines didácticos.

La elección de todos los proyectos se ha realizado a partir de una extensa labor de

descarte, ya que se han buscado aplicaciones y páginas web que cumpliesen una serie de

requisitos entre los que se incluyen: estar traducidas a más de un idioma y presentar un

mínimo de pautas propias del proceso de internacionalización.

En definitiva, los objetivos del estudio son varios:

Mostrar y ejemplificar aquellos aspectos deficientes en la internacionalización y

localización que deberían mejorarse en los proyectos examinados.

37

Demostrar la importancia de seguir ciertas pautas en el proceso de

internacionalización y exponer las consecuencias que pueden surgir al no seguir

dichas pautas.

Llevar a cabo una comparación que demuestre el contraste existente entre el

número de casos de proyectos que se desarrollan pensando en el localizador o

traductor, frente a todos aquellos en los que apenas se dedica un momento a

pensar en la existencia de su labor.

No obstante, antes de comenzar con el mismo, considero importante conocer algo más a

fondo qué es el código abierto y en qué consiste el crowdsourcing exactamente:

Howe (2006) proporciona la siguiente definición del término crowdsourcing, la cual

Jiménez-Crespo (2017, 15) recoge en su libro dedicado a esta práctica:

“The act of taking a job traditionally performed by a designated agent […] and outsourcing it to an

undefined, generally large group of people in the form of an open call. This can take the form of

peer-production, but it is also often undertaken by a sole individual.”

En definitiva, se trata de una práctica por lo general online que empresas, instituciones y

otros colectivos llevan a cabo con el objetivo de conseguir un determinado fin

valiéndose para ello de voluntarios, profesionales, fans, expertos, etc. (Jiménez-Crespo

2017, 12).

En cuanto al código abierto:

“The term ‘open source’ refers to software whose source code is freely available to download, edit,

use and share. There are different open source licenses, which give users different degrees of

freedom, but the main aim of open source is to encourage collaboration. […] It’s usually

maintained by a community and updated frequently to patch vulnerabilities or squish bugs as soon

as they’re identified; there are no restrictions on commercial use, so you can happily use it for your

home business […]” (AA.VV, s.d).

Por último, es necesario saber que antes del propio desarrollo del análisis de cada

aplicación o página web, se ha incluido una tabla a modo de resumen:

38

11.2. Aplicación de escritorio GnuCash:

GNU CASH

¿Página web, aplicación móvil o aplicación de escritorio?

Aplicación de escritorio.

Lenguaje de programación. C y Scheme.

Cadenas de texto incrustadas/ separadas. Separadas.

Estilos, colores, fuente, etc. incrustados/ separados.

Separados.

¿Hay comentarios para los desarrolladores?

Sí.

¿Hay comentarios para los traductores? Sí.

¿Se han marcado los comentarios con uniformidad?

Sí.

¿Hay glosarios, guías de estilo, etc.? Sí.

¿Están marcadas las cadenas que hay que traducir?

Sí.

¿Nombres de las variables significativos? Sí.

¿Unicode UTF-8? Sí.

¿Hay placeholders? Sí.

¿Son los placeholders intuitivos o hay comentarios para ellos?

Sí.

¿Hay capturas de pantalla o vídeos que requieran localización?

Sí.

¿Texto incrustado en gráficos, iconos…? No.

¿Es fácil localizar donde seleccionar el idioma?

No.

¿Nombre de los idiomas en idioma origen?

Sí (instalador).

¿Están los recursos organizados en carpetas?

Sí.

39

Antes de comenzar el análisis de este proyecto, debemos decir que en la propia wiki del

mismo se nos informa de que la rama más estable es la que recibe el nombre de maint.

Por esto mismo, esta ha sido la rama que hemos descargado y con la que hemos

trabajado:

“GnuCash uses Git as a version control system. […] The first thing to do is usually, to download

the latest STABLE branch, called maint, of Gnucash from git and get it to

compile. See Translation Status to choose which branch to use for translations. Do not use

the master branch unless specifically mentioned in Translation Status. Because the text in

the master branch changes so much it would be a waste of time to translate it. Do not worry; when

the master branch becomes stable the existing translations in the STABLE branch will be merged.

Your work will not be lost.”

Además, es importante mencionar que en esta misma wiki

(https://wiki.gnucash.org/wiki/GnuCash) podemos encontrar una gran cantidad de

pautas e información útil para todos aquellos que quieran colaborar en calidad de

programadores, traductores, revisores, etc. Por otra parte, también existe una página

tremendamente extensa dedicada de forma exclusiva a la traducción de esta aplicación

(https://wiki.gnucash.org/wiki/Translation).

«GnuCash forma parte del proyecto Gnome y, como tal, utiliza las mismas herramientas para su

desarrollo, como por ejemplo el sistema de listas de correo para la comunicación entre

desarrolladores y también entre usuarios, la notificación de errores y la preparación de las

diferentes versiones lingüísticas. Hay además una wiki donde se recoge documentación y guías

adicionales». (AA.VV, 2018).

Así pues, para conseguir mayor rigor en nuestro análisis, también hemos leído y

analizado al detalle dichos sitios webs, de los que hemos extraído información que se

expondrá a lo largo del presente análisis:

11.2.1. Presentación:

Dentro del propio proyecto podemos encontrar un archivo con extensión .txt donde se

realiza una presentación de este programa de ordenador o aplicación de escritorio:

Figura 1: Descripción de GnuCash.

En definitiva, estamos ante un programa de contabilidad y finanzas para uso personal o

en pymes que es compatible con GNU/Linux, BSD, Solaris, Mac OS X y Windows.

https://wiki.gnucash.org/wiki/GnuCash

https://wiki.gnucash.org/wiki/Translation

40

11.2.2. ¿Están las cadenas de texto separadas del código fuente o incrustadas en el

mismo?

En el proyecto también encontramos una carpeta que recibe el nombre de po, un

formato muy común de los archivos de traducción. Por esto mismo y como bien hemos

intuido, en dicha carpeta encontramos archivos con extensión .po que almacenan las

cadenas de texto traducidas a los distintos idiomas en los que se ofrece este programa.

Figura 2: Carpeta con los archivos .po

Si por ejemplo abrimos el archivo correspondiente al idioma español de España,

podemos observar varias cosas:

En primer lugar, al inicio del archivo encontramos información el nombre de

traductores que han contribuido, así como su correo electrónico y las fechas en las que

han realizado su aportación (figura 3).

41

Figura 3: Información sobre los traductores contribuyentes.

La presencia de este tipo de información se explica porque desde la página de GnuCash

destinada a la traducción de dicho programa se nos aconseja ponernos en contacto con

el último traductor. Entendemos que el objetivo de esta práctica es mantener la

uniformidad en todo el proyecto, así como comenzar a realizar el trabajo justo donde el

traductor anterior lo dejó para que no se produzca una duplicación de tareas:

“Look to see who the "Last-translator" was, and send an email to that person and ask what you can

do to help. This is important because if there already is an active maintainer of the translation file,

you should interact directly with him or her. If there is no Last-Translator, or that person is not

maintaining the file actively (and tells you to take over or does not answer in reasonable time), you

will become the maintainer and you should change the "Last-Translator" to your name and email

address.”

Figura 4: En la parte superior de los archivos .po deberán aparecer los datos del último traductor.

Por otra parte, en el archivo es.po también podemos ver que, efectivamente las cadenas

de texto no están incrustadas dentro del código fuente del programa, pues justo encima

de cada cadena de texto en el idioma original (inglés), se nos informa sobre el archivo

concreto, la ruta de acceso y la línea de donde se ha extraído dicha cadena.

Figura 5: Ruta de acceso del archivo donde se ha extraído la cadena de texto.

42

Figura 6: La cadena de texto efectivamente está en el archivo y línea indicados.

A continuación se muestran más ejemplos:

Figura 7: Ruta de acceso de otra cadena de texto.

Figura 8: Una vez más la cadena está en la ruta y línea indicadas.

Esta práctica puede resultar tremendamente beneficiosa, pues no solo demuestra que las

cadenas de texto no están incrustadas en el código fuente, sino que además, si como en

este caso tenemos acceso a todo el proyecto, esto nos permitirá consultar el archivo de

donde se ha extraído una determinada cadena de texto con la finalidad de conseguir

mayor contexto que nos ayude en la traducción de la misma.

11.2.3. ¿Están los estilos, colores y fuentes separados del código fuente o

incrustados en el mismo?

En la página web del proyecto existe también un apartado dedicado a la arquitectura del

programa donde nos informan de que separar la interfaz de los datos forma parte de su

filosofía: “We must maintain a clean separation between the data structures and the GUI

that manipulates them, along the lines of the Model-View-Controller paradigm.”

Como bien hemos comprobado, esta filosofía se cumple, pues por ejemplo, en el

proyecto encontramos una carpeta que recibe el nombre de stylesheets donde se alojan

los distintos estilos.

43

Figura 9: Carpeta donde se alojan los estilos de la aplicación.

11.3.4. Comentarios:

Una vez más en la wiki del proyecto, pero en este caso en la página dedicada a la

traducción del mismo, podemos encontrar el apartado “How to give the translators a

clue”, en el que se habla del beneficio de añadir comentarios para facilitar la labor de

los traductores:

“Sometimes it is useful to give the translators some additional information about the meaning of a

string. To achieve this effect, you can insert a section of comment lines direct before the related

string, where the first comment starts with "Translators:” There must not be any control statement

between comment and string.”

Además, también se proporciona información sobre las distintas sintaxis de comentarios

que se van a poder encontrar en el proyecto en función del tipo de archivo:

Figura 10: Sintaxis de comentarios para el lenguaje de programación C.

44

Figura 11: Sintaxis de comentarios para los archivos .po y .pot

Figura 12: Sintaxis de comentarios para los archivos SCM.

Figura 13: Sintaxis de comentarios para los archivos glade.

Así pues, para comprobar si efectivamente hay comentarios para los traductores, hemos

decidido buscar la palabra translators dentro del archivo es.po. Para nuestra sorpresa, la

búsqueda nos ha devuelto 96 resultados que se corresponden con 96 comentarios

destinados a los traductores.

45

Figura 14: Se han obtenido 96 resultados al buscar la palabra “translators”.

Tras revisar todos los comentarios, podemos decir que estos tienen como fin

proporcionar pautas sobre la formación de plurales, remitir a un segundo documento en

el que se puede ampliar la información sobre una cadena de texto en concreto, aportar

mayor contexto o hacer aclaraciones terminológicas. A continuación exponemos tres

ejemplos para que sirvan de muestra:

Figura 15: Comentario con aclaración terminológica.

Figura 16: Comentario con aclaración terminológica.

Figura 17: Comentario que aporta contexto.

En lo que respecta a los comentarios para los propios desarrolladores, también hemos

encontrado una gran cantidad, aunque en este caso no nos ha supuesto una sorpresa:

46

Figura 18.

Figura 19.

Figura 20.

11.2.5. Glosarios, memorias de traducción, guías de estilo:

Dentro de la carpeta po no solo encontramos los archivos que contienen las cadenas de

texto en los distintos idiomas, sino que también encontramos una segunda carpeta que

recibe el nombre de glossary y que, tal y como se puede intuir, contiene un glosario

para cada idioma.

A este respecto es necesario aclarar que dentro de la carpeta po existe además un

archivo README donde se aconseja traducir el glosario antes de proceder con la

traducción de las cadenas de texto.

47

Figura 21: Se aconseja traducir el glosario antes que las propias cadneas de texto.

Una vez leído el archivo gnc-glossary.txt, podemos afirmar que se trata de un glosario

relativamente completo. No obstante, al tratarse de un programa de contabilidad, la

traducción va a estar principalmente adscrita al área económico-financiera, un área de la

traducción que, como cualquier otra área, requiere de un alto nivel de conocimiento y

especialidad. Por esto mismo, independientemente de su completitud, el glosario

siempre va a poder ser más específico, técnico y aportar mayor información de la que ya

aporta.

Por otro lado, dentro de la wiki dedicada a la traducción del programa y ya mencionada

en varias ocasiones a lo largo del presente análisis, también vamos a poder encontrar un

apartado en el que se nos ofrece la posibilidad de consultar varios links adicionales que

son de gran interés para la traducción del proyecto.

Figura 22: Links de interés para la traducción del proyecto.

48

En uno de estos enlaces se adjuntan varias direcciones que se corresponden con distintas

herramientas de traducción:

Figura 23: Captura extraída de http://translationproject.org/html/software.html

11.2.6. ¿Están las cadenas traducibles marcadas?

Nuevamente dentro de la carpeta po encontramos dos archivos relacionados con la

traducción de las cadenas de texto: por un lado el archivo POTFILES.in y por otro el

archivo POTFILES.ignore.

En ellos se recogen las rutas de acceso de los archivos que sí requieren traducción

(POTFILES.in ) y también aquellas que no es necesario traducir porque no se muestran

al usuario (POTFILES.ignore).

Figura 24: Archivos que contienen cadenas de texto traducibles.

http://translationproject.org/html/software.html

49

Figura 25: Archivos que no hay que traducir.

11.2.7. ¿Son los nombres de las variables significativos?

Como ya se ha comentado previamente en este trabajo, el lenguaje de programación C

empleado para desarrollar esta aplicación de escritorio es un lenguaje tipado. Por esto

mismo, es necesario declarar el tipo de las variables y darles un nombre que sirva de

identificador de las mismas.

Como bien hemos dicho, esta aplicación forma parte del proyecto GNOME, una

fraestructura de desarrollo para sistemas operativos GNU (AA.VV, s.d).

Así pues, si acudimos a la página web de GNU, dentro de la misma existe un apartado

dedicado a mencionar la importancia de dar un nombre a las variables que resulte

intuitivo y signifiativo:

“The names of global variables and functions in a program serve as comments of a sort. So don’t

choose terse names—instead, look for names that give useful information about the meaning of the

variable or function. In a GNU program, names should be English, like other comments.”

(AA.VV, s.d).

No obstante, hemos querido comprobar si en el desarrollo de esta aplicación se ha

seguido esta pauta. Por esto mismo, hemos seleccionado varios archivos con extensión

.c y extraído de los mismos algunas variables:

Figura 26: Variables de tipo char.

50

Figura 27: Variables de distintos tipos.

Como podemos ver, nombres como text, type_name, file_retention_policy, etc resultan

nombres bastante completos e intuitivos. No obstante, es cierto que no disponemos de

tiempo suficiente para observar todas y cada una de las variables presentes en el

proyecto, pues este tampoco es el tema central de este estudio.

11.2.8. Codificación:

Si buscamos «UTF-8» en el buscador de Visual Studio Code, los resultados nos

permiten intuir que aunque muchos de los archivos del proyecto emplean la codificación

UTF-8 –ya que además hay archivos que contienen caracteres propios del árabe o el

chino-, no todo el proyecto sigue esta misma codificación, pues por lo que podemos leer

en algunos archivos, se intuye que existe algún problema a la hora de implementar esta

codificación en esta aplicación de escritorio. No obstante, los archivos .po sí están en

UTF-8:

Figura 28.

En lo que se refiere a la bidireccionalidad, tras instalar el programa en árabe, podemos

concluir que aparentemente este idioma se muestra y procesa adecuadamente. No

obstante, no hemos tenido la posibilidad de combinar dos idiomas con distinta dirección

de escritura para probar si ambos se mostraban de manera adecuada.

11.2.9. Placeholders:

Para determinar la presencia tanto de placeholders como de comentarios que den una

explicación o aclaración a los mismos, nos hemos servido nuevamente del archivo

es.po, pues la búsqueda de comentarios para los traductores nos ha llevado a descubrir

que gran cantidad de los mismos están destinados a proporcionar información sobre los

placeholders que pueden encontrarse en ciertas cadenas de texto.

Tras revisar todos los que aparecen en es.po, hemos determinado que por lo general se

emplean para hacer referencia a números (%d) o archivos o nombres de elementos (%s).

51

Figura 29: Placeholder que hace refrencia a una ruta de acceso.

Figura 30: Placeholder que hace referencia a un número.

Figura 31: Placeholder que hace referencia a una divisa.

11.2.10. ¿Hay capturas de pantalla o vídeos que requieran localización?

En GitHub también podemos encontrar el repositorio que se corresponde con el manual

de usuario de este programa, por lo que hemos considerado oportuno descargarlo y

analizar algunos aspectos muy concretos del mismo.

En primer lugar, cabe decir que en la wiki de GnuCash se nos informa de que «la última

versión del manual del programa en español es la referente a la versión 1.6». Este hecho

es efectivamente cierto, pues si abrimos el tutorial de uso desde la opción de ayuda del

propio programa, este se muestra en inglés:

52

Figura 32: Tutorial en inglés.

Por otra parte, cabe descatacar que este manual contiene varias carpetas con gran

cantidad de capturas de pantallas que requerirían localización.

Con respecto a esto, se hace referencia a este tema y se dan algunas pautas sobre el

mismo en la propia wiki del programa:

Figura 33: Pautas para la localización de las capturas de pantalla.

Así pues, hemos encontrado las capturas localizadas al alemán, japonés, italiano,

portugués y ruso, pero no a ninguno de los otros idiomas en los que –en principio- está

traducido el programa.

53

Figura 34: Captura localizada al alemán.

Figura 35: Captura localizada al italiano.

54

Figura 36: Captura localizada al japonés.

Figura 37: Captura localizada al portugués.

55

Figura 38: Captura localizada al ruso.

Figura 39: Captura en el idioma de origen.

56

Por último, no hemos encontrado vídeos que sirvan como tutoriales y que requieran

localización.

11.2.11. ¿Tienen las imágenes, gráficos, iconos, etc. texto incrustado?

Dentro de la página web del proyecto gnome (https://developer.gnome.org/)

encontramos un apartado dedicado a los iconos. En este apartado se hace énfasis en que

los iconos tienen que ser representativos o fáciles de entender, aspecto que ya se ha

comentado en la primera parte del presente trabajo.

«Use sólo iconos cuyo significado es comúnmente reconocido. Si no hay disponible un icono

reconocido habitualmente, es preferible usar una etiqueta de texto en su lugar».

En el caso del programa de ordenador GnuCash, podemos afirmar que los iconos que

hemos encontrado no solo no tienen texto incrustado, sino que además son bastante

sencillos e intuitivos:

Figura 40: Iconos.

Figura 41: Iconos.

Figura 42: Iconos.

https://developer.gnome.org/

57

11.2.12. Selección del idioma:

Si descargamos el programa, en el proceso de instalación del mismo se nos permite

elegir el idioma en el que queremos que se muestre cada vez que lo iniciamos.

Esta selección de idioma pues, se lleva a cabo a cabo desde el instalador:

Figura 43: Selección del idioma en el instalador.

Como podemos ver, no se ha seguido un criterio uniforme a la hora de traducir los

nombres de los distintos idiomas, pues por ejemplo el japonés, el griego o el chino –

entre otros- se han escrito en inglés, mientras que otros idiomas como el catalán, francés

o alemán se han escrito en sus respectivos idiomas.

Además, si prestamos atención a la selección de idiomas, no se nos ofrece la posibilidad

de que el programa esté en español, lo que resulta bastante sorprendente si tenemos en

cuenta que existe un archivo .po que corresponde con el español de España y cuya

traducción además está completa.

Esto se explica porque en función del idioma en el que queramos visualizar el programa

no podremos elegir el idioma desde el instalador ni desde el propio programa, sino que

se deberán seguir las instrucciones recogidas en la imagen que se muestra a

continuación:

58

Figura 44: Extraída de http://eduwebblog.blogspot.com.es/2014/02/gnucash-261-en-espanol.html

Este problema también se avisa en el apartado de documentación de la página de

GnuCash:

Figura 45: No se puede cambiar el idioma del programa desde el propio.

http://eduwebblog.blogspot.com.es/2014/02/gnucash-261-en-espanol.html

59

Así pues, para poder iniciar el programa en español hemos tenido que seguir las

instrucciones de la figura 45.

Con respecto a esto, es evidente que a pesar de que haya sido un proceso relativamente

sencillo y breve, resulta tremendamente incómodo y confuso, pues seguramente la

mayor parte de los usuarios que se descarguen el programa y no vean su idioma en la

lista de selección pensarán directamente que no existe una traducción de dicho

programa para su lengua materna.

Por otra parte, aun en el caso remoto de que descubriesen que existe la posibilidad de

visualizar el programa en idiomas que no se recogen en el menú desplegable mostrado

en la figura 43, es posible que no sepan seguir adecuadamente los pasos necesarios para

conseguir esto.

60

11.3. Aplicación de escritorio Notepad++:

El segundo programa que se va a analizar, se corresponde con una aplicación de

escritorio bastante conocida tanto por los localizadores como por los desarrolladores.

NOTEPAD++ 7.5.6


Aplicación de escritorio.

Lenguaje de programación. C++.



Separados.

¿Hay comentarios para los desarrolladores? Sí.



Sí.

¿Hay glosarios, guías de estilo, etc.? No.


Sí.





Sí.


Sí.



Sí.

¿Nombre de los idiomas en idioma origen? Sí.


Sí.

61

11.3.1. Introducción:

Tal y como se afirma en un archivo README incluido en el propio proyecto,

Notepad++ es un editor gratuito de código fuente desarrollado en C++ y basado

Scintilla, un potente componente de edición de código.

A pesar de que está especialmente pensado para que los programadores editen código

con él, presenta muchísimas otras utilidades como editor de texto que, de hecho, pueden

ser realmente ventajosas para los traductores. Ejemplo claro de esto es que permite abrir

y manipular archivos TTX, una función que, a pesar de que podría llevarse igualmente a

cabo con el bloc de notas habitual, es más aconsejable realizar con Notepad++, pues

presente ventajas como marcar los distintos elementos de la sintaxis de los archivos xml

en colores diferentes, lo que facilita identificar o localizar visualmente los distintos

elementos. Por otra parte, también posee una potente función de buscar y reemplazar,

que también resulta muy útil para trabajar con glosarios. Además de esto, permite abrir

varios documentos al mismo tiempo e incluso trabajar con ellos en vista múltiple.

Notepad ++ es compatible con numerosos lenguajes naturales y varios lenguajes de

programación entre los que se incluyen algunos de los mencionados en el apartado del

presente trabajo dedicado a la programación; este editor de código también ofrece al

usuario la posibilidad de añadir un idioma propio y trabajar con el mismo. (Cevoli,

2016).


mismo?

Con respecto a las cadenas, no solo hemos encontrado la carpeta en la que se alojan los

archivos que contienen las cadenas de texto en los distintos idiomas a los que

Notepad++ está traducido, sino que además hemos localizado el archivo donde se aloja

la función que -de manera muy simplificada- podemos decir que detecta el idioma que

seleccionemos en el instalador, se encarga de comprobar que dicho idioma es válido y

genera el código correspondiente al idioma seleccionado. Además, transforma este

código en un tipo de dato que puede procesar el lenguaje C++ a través de c_str. (Figura

46)

Seguidamente, se pasa la información a la función NppParameters::getLocPathFromStr

alojada en otro archivo.

62

Figura 46.

Si buscamos esta última función en Visual Studio Code, encontramos el archivo

Parameters.cpp, donde dicha función recibe el código que ha generado la anterior. Por

esto mismo, como podemos ver, la función NppParameters::getLocPathFromStr toma

como parámetro localizationCode –cuyo nombre nos permite intuir perfectamente que

se trata del código que se ha generado previamente y que corresponde a un determinado

idioma- y devuelve el archivo xml donde están las cadenas de texto en el idioma

correspondiente.

Figura 47: Archivo Parameters.cpp

De esta manera, queda perfectamente demostrado que las cadenas de texto están

separadas del código y alojadas en archivos aparte, más concretamente dentro de la

carpeta nativeLang, que a su vez se encuentra dentro de la carpeta del instalador

(installer):

63

Figura 48: Archivos xml con las cadenas de texto.

Como hemos explicado a lo largo del presente trabajo, mediante la extracción de las

cadenas de texto conseguimos evitar que se produzcan posibles rupturas del código a la

hora de realizar la traducción. Sin embargo, esto también supone una desventaja, ya que

al separar las cadenas de texto del resto del código fuente se pierde la información

contextual que en un determinado momento puede proporcionar ese código (nombres de

las variables, funciones, etc.). A esto se suma que, a pesar de que en este caso tenemos

acceso a todo el programa por tratarse de una aplicación de código abierto, por lo

general al traductor tan solo se le proporcionan los archivos donde se alojan las cadenas

de texto.

Así pues, aunque separar las cadenas de texto facilita la labor tanto a los propios

desarrolladores como al traductor, también la dificulta de cierta forma. Esta dificultad se

ve agravada si apenas hay comentarios que acompañen a determinadas cadenas de texto

que puedan resultar ambiguas, presentar problemas terminológicos, etc. De ahí la

importancia de los comentarios.

En relación con la separación de las cadenas de texto que se ha realizado en Notepad++,

considero oportuno señalar que tras analizar minuciosamente otros productos de

software en este mismo estudio, he llegado a la conclusión de que puede resultar más

cómodo para el traductor el hecho de que en el archivo que se corresponde con las

cadenas de un determinado idioma meta, se muestre en primer lugar la cadena original y

seguidamente el espacio –generalmente entre comillas inglesas- donde se debe colocar

la traducción de dicha cadena, ya que esta práctica permite visualizar el texto origen en

todo momento. Sin embargo –y como bien se muestra en la siguiente figura-, en

Notepad++ nos dicen que para realizar la traducción simplemente debemos descargar el

archivo english.xml donde están las cadenas de texto originales, y sustituirlas por las

64

cadenas traducidas. De esta forma, no se están conservando las cadenas originales que

nos pueden servir de referencia a la hora de realizar la revisión de las mismas o si

queremos consultar cómo habíamos traducido un determinado término con el fin de

mantener la uniformidad y coherencia en cadenas ulteriores.

Figura 49: Para realizar la traducción simplemente hay que descargar el archivo english.xml



Si hacemos clic con el botón derecho del ratón en un archivo programado en C++

mientras pulsamos la tecla Control, Visual Studio Code nos dirige al archivo donde

están los colores, lo que demuestra que efectivamente estos no están incrustados en el

código. Además, como podemos ver en las figuras que se muestra abajo, se ha

empleado el método RGB para expresar dichos colores:

Figura 50: Si pinchamos sobre darkGreen, Visual Studio Code nos lleva al archivo colors.h

65

Figura 51: Archivo donde están todos los colores de esta aplicación de escritorio.

Al igual que los colores, los temas también constituyen archivos independientes con

extensión xml. En este caso se alojan en la carpeta themes, que a su vez está dentro de la

carpeta installer.

Figura 52: Carpeta donde se encuentran los temas.

Si a continuación buscamos el nombre de uno de estos temas en el buscador de Visual

Studio Code, podemos ver como se está llamando a estos archivos xml:

66

Figura 53.


Tras analizar la presencia de comentarios destinados a los traductores en el archivo

donde se alojan las cadenas de texto originales (english.xml), podemos asegurar que tan

solo hemos encontrado tres comentarios destinados a estos profesionales:

Figura 54: Comentario que indica que no se debe traducir nada a partir del mismo.

Además, dos de estos tres comentarios hacen referencia a placeholders:

Figura 55: Comentario sobre un placeholder.

67

Figura 56: No se deben traducir los placehoders.

En contraste con esto, el número de comentarios destinados a desarrolladores que

hemos encontrado ha sido destacadamente superior:

Figura 57.

Figura 58.

Figura 59.

68

Además, cabe añadir que dentro de este proyecto hemos encontrado un archivo que

recibe el nombre de CONTRIBUTING. En él se proporcionan una serie de pautas o

buenas prácticas que los desarrolladores deberían seguir y entre las que se incluye

emplear la sintaxis de comentarios del lenguaje C++.

Figura 60: Sintaxis de comentarios del lenguaje C++.


A pesar de que la traducción de este proyecto la realizan todos aquellos usuarios que

desean colaborar de manera totalmente voluntaria y que, como es imaginable, en

muchas ocasiones no serán traductores profesionales, no hemos encontrado ni un solo

recurso que les sirva de ayuda. A esto se suma el ya comentado aspecto de que tan solo

encontramos tres comentarios destinados a los traductores.

La única pauta que se nos ofrece desde la propia página web de Notepad++ es que

descarguemos el archivo english.xml y lo traduzcamos a nuestro idioma, así como el

procedimiento que hay que seguir para comenzar a traducir:

Figura 61: Procedimiento para realizar la traducción de Notepad++.


Aunque las cadenas traducibles no están macadas como tal, en la página web se

proporciona una indicación sobre las cadenas que requieren traducción.

69

Además, algo que ha captado nuestra atención es que en este mismo párrafo se realiza

una aclaración sobre el tratamiento del carácter “&”, el cual resultará muy familiar para

un localizador con experiencia pero que sin embargo puede suponer un problema para

todos aquellos que se enfrenten a una labor de localización por primera vez:

“& in the Tag Menu is &, it takes effect (draw a underline on a letter) when user push

the Alt key. So it's up to you to change its position, it depends on the menu convention of your

language.”


Dentro del archivo CONTRIBUTING al que se ha hecho referencia de forma previa, se

dan pautas que favorecen la uniformidad y el trabajo colectivo organizado. Entre esas

pautas se incluyen la de dar nombres significativos a las variables:

Figura 62: Se recomienda emplear nombres de variables descriptivos.

Tal y como se recoge en la tabla inicial, Notepad++ está programado fundamentalmente

en C++, un lenguaje de programación también tipado, en el que la declaración de

variables se realiza de la misma manera que en el lenguaje C.

Así pues, tras localizar unas cuantas variables entre los archivos con extensión .cpp,

podemos afirmar que por lo general los nombres de las variables son intuitivos. Ej:

srcLagnsPath, loadOky o nativeLangPath. (Figuras 63 y 64).

70

Figura 63.

Figura 64.

No obstante, también encontramos variables cuyo nombre reuslta demasiado críptico

(figura 65).

Figura 65: “i” es un nombre demasiado enigmático para una variable.


Como bien se ha aclarado en la introducción, Notepad++ permite trabajar con gran

cantidad de lenguajes naturales entre los que se incluyen idiomas como el árabe o el

hebreo. Así, hemos querido comprobar si permite la manipulación de textos en dichos

dos idiomas. Por esto mismo, resulta evidente que en el proceso de internacionalización

se debería haber adaptado la aplicación para que sea compatible con la

bidireccionalidad. De hecho, se utiliza la codificación UTF-8:

Figura 66: UTF-8.

Sin embargo, en el propio sitio web de Scintilla, componente de edición en el que, como

hemos dicho, se basa Notepad++, se aclara lo siguiente:

“Scintilla does not properly support right-to-left languages like Arabic and Hebrew. While text in

these languages may appear correct, it is not possible to interact with this text as is normal with

other editing components.”

Con el fin de comprobar si esta aclaración es efectivamente cierta, hemos procedido a

instalar el programa en árabe y trabajar con un texto en dicho idioma, pues el hebreo no

se encuentra entre los idiomas que forman parte de mi combinación lingüística. He de

decir que aparentemente todo parece funcionar de forma adecuada tanto en lo que se

refiere al procesamiento de dicho idioma como a la muestra del mismo, ya que el texto

71

y los caracteres se muestran correctamente y al realizar una búsqueda, el resultado de la

misma ha sido satisfactorio:

Figura 67.

Sin embargo, a la hora de trabajar con varios idiomas a la vez, hemos podido comprobar

que efectivamente se dan problemas. Por ejemplo, si estamos trabajando en un

documento en español e introducimos un fragmento de texto en árabe, este último se

pega al margen de la izquierda en lugar de al de la derecha. Además, si en este mismo

documento en el que se está empleando tanto el español como el árabe realizamos una

búsqueda de un término en árabe, los caracteres árabes se desordenan en la barra de

búsqueda:

72

Figura 68: Caracteres árabes desordenados en la función «buscar».

Podemos concluir entonces que, en lo que se refiere a uno de los aspectos

fundamentales en la internacionalización y localización de productos informáticos como

es la bidireccionalidad, este programa presenta problemas. Esto seguramente se debe a

alguna deficiencia en el empleo de la propiedad unicode-bidi que permite la

combinación en un mismo documento de varios idiomas cuya dirección de escritura es

diferente.


Como ya se ha comentado en el apartado destinado a los comentarios, de entre los tres

comentarios que hay a lo largo de todo el proyecto dirigidos a los traducotres, dos de

ellos son aclaraciones sobre placeholders.

En concreto encontramos dos placeholders en este proyecto: $STR_REPLACE$, que

por contexto deducimos que hace referencia a un elemento textual, y

$INT_REPLACE$, que parece hacer referencia a un número:

Figura 69: Placeholder que hace referencia a un elemento textual.

73

Figura 70: Placeholder que hace referencia a un valor numérico.


Notepad++ cuenta con un manual de ayuda oficial en formato pdf que puede

descargarse desde la propia página web de este programa. No obstante, dicho manual

tan solo está en inglés, lo que obviamente nos indica que las capturas de pantalla que

sirven de apoyo al mismo tampoco están localizadas a otros idiomas.

Figura 71: Captura del manual que requeriría localización si se tradujese el manual.

Por otra parte, no hemos encontrado ningún tutorial en formato video que pudiese

requerir localización.

74

11.3.11. ¿Tienen las imágenes, gráficos, etc. texto incrustado?

Por lo que respecta a los iconos, gráficos e imágenes, parece que sí se han seguido

pautas de internacionalización que favorecen la localización, ya que ningún elemento

salvo el propio logo del programa tiene texto incrustado:

Figura 72.

Figura 73.

Figura 74.


En cuanto a la selección del idioma, esta debe hacerse desde un menú desplegable en el

instalador, donde podemos ver que el nombre de cada idioma se ha mantenido en el

idioma original.

75

Figura 75. Figura 76.

No obstante, en la página web del programa el nombre del idioma aparece solamente en

inglés. Además, se utilizan banderas para indicar el mismo, lo que como se ha expuesto

en la primera parte de este trabajo, puede conllevar problemas culturales.

Figura 77: Se desaconseja el empleo de banderas como iconos representativos de un determinado idioma.

76

11.3.13. Errores:

Antes de finalizar el análisis de Notepad++, hemos considerado oportuno dedicar un

apartado adicional a la mención de una serie de errores detectados en la realización de

dicho análisis.

En primer lugar, como bien se muestra en la siguiente figura, existen problemas de

coherencia entre sustantivos y adjetivos:

Figura 78: Problema de coherencia.

También podemos ver como en determinados menús se produce una mezcla de idiomas,

lo que nos puede llevar a imaginar que no todas las cadenas de texto están traducidas al

español. De hecho, algunos menús están en inglés en su totalidad (figura 80):

Figura 79: Fragmentos sin traducir.

77

Figura 80.

Por otra parte, hemos detectado problemas de espacio, algo que como sabemos podría

evitarse si en el proceso de internacionalización los desarrolladores no establecen unas

dimensiones fijas para las cadenas.

Figura 81: Problema de espacio.

Sin embargo, en otras ocasiones, en lugar de oraciones cortadas por la limitación de

espacio, nos encontramos con truncamientos:

Figura 82: Truncamiento.

78

11.4. Aplicación móvil Pamplona Negra:

Una vez analizadas dos aplicaciones de escritorio, pasamos a analizar dos aplicaciones

para móviles:

PAMPLONA NEGRA


Aplicación móvil.

Lenguaje de programación. Java.



Separados.


Sí.

¿Hay comentarios para los traductores? No.


Sí.

¿Hay glosarios, guías de estilo, etc.? No.


No.



¿Hay placeholders? No.


No.


Sí.



Sí.


Sí.


Sí.

79


La aplicación «Pamplona Negra» es una aplicación para móviles con sistema operativo

Android que los alumnos del grado superior de Desarrollo de Aplicaciones

Multiplataforma del instituto Cuatrovientos de Pamplona desarrollaron con motivo de la

celebración de la semana negra de dicha ciudad. Se trata de una aplicación bastante

sencilla que consiste en una serie de acertijos. Para resolver los mismos, es necesario

activar la ubicación de tu teléfono móvil y acudir a distintos lugares emblemáticos o

monumentos de Pamplona -a los que se hace referencia en los acertijos-, con el fin de ir

recopilando pistas y llegar a la pantalla final del juego.

Figura 83: Descripción de la aplicación en el Google Play Store.

Esta aplicación se ha desarrollado con Android Studio y está programada en Java.

Para el análisis de los distintos factores presentados en la tabla inicial, nos vamos a

centrar en la carpeta main (app> src> main), pues es donde se encuentran todos los

archivos que son de nuestro interés. El resto de carpetas contienen dependencias,

archivos de configuración y demás elementos generados automáticamente por Android.

Dentro de la carpeta main, podemos ver otras tres carpetas: assets, java y res, así como

dos imágenes de la interfaz de la aplicación y el manifiesto de Android.

80

Figura 84: Contenido de la carpeta main.

Si abrimos la carpeta java, accederemos a los archivos que contienen el código fuente

de la aplicación:

Figura 85: Archivos con extensión .java.

Dado que se ha desarrollado en Android Studio, vamos a servirnos de este mismo

entorno de desarrollo para ir analizando detalladamente la aplicación.

81


mismo? ¿Y los estilos, colores y fuentes?

Si accedemos al archivo Credit Activity ya podemos comprobar que la interfaz está

separada del código fuente, y es que al llegar el código a la línea en la que se ejecuta el

método onCreate (línea 17), seguidamente vemos cómo se ejecuta el método

setContentView, que como su propio nombre permite intuir, va a hacer que se ofrezca

una interfaz al usuario.

Figura 86.

Para ofrecer esta interfaz, al ejecutarse el método setContentView se llama al archivo

activity_credit, que está alojado en la carpeta resources (R) y a su vez en la carpeta que

recibe el nombre layout.

Figura 87.

82

Si pinchamos sobre el archivo activity_credit con el botón derecho del ratón al mismo

tiempo que pulsamos la tecla Control, Android Studio nos lleva hasta dicho archivo, de

forma que nos encontramos lo siguiente:

Figura 88: Pantalla de créditos de la aplicación.

Como podemos ver, esta es una de las vistas que se muestran al usuario, más

concretamente la pantalla de créditos.

Dentro de esta vista también podemos comprobar que tanto los colores como las

cadenas de texto están extraídos, guardados en archivos específicos, y por tanto

separados del código fuente. Para verificar esto basta con clicar en el botón verde que

aparece en la parte inferior de la vista: al realizar esta acción, Android Studio nos

muestra un menú en la parte derecha de la pantalla donde se muestran una serie de datos

referidos a este botón.

Figura 89: Si clicamos sobre este botón nos aparece más información sobre él.

83

Figura 90: Menú desplegable que contiene información sobre el botón.

En primer lugar, como bien nos indica el apartado ID, vemos que el nombre que los

desarrolladores han dado a este botón es btnCredits.

Figura 91: Información sobre el botón.

84

En el subapartado BackgroudTint se muestra cómo el color de dicho botón se halla en

una carpeta específica, más concretamente en la carpeta que recibe el nombre color y

que está dentro de la carpeta res (resources). En cuanto al nombre del color, este se

corresponde con blackweek_green.

Por otra parte, también podemos ver que los desarrolladores han utilizado el método

hexadecimal para expresar el color (#aefd34) y no el método RGB empleado en

Notepad++.

Figura 92: Archivo que contiene todos los colores de la aplicación.

El texto que contiene el botón, que en este caso es «¡Gracias por su visita!», también

está guardado en una carpeta específica donde se encuentran las demás cadenas de texto

de la aplicación. Esto podemos comprobarlo porque en el apartado TextView de Android

Studio, @string/credits_button nos indica que dicha cadena de texto se identifica como

credits_button y está alojada dentro de la carpeta strings. En definitiva, se nos indica la

ruta de acceso.

85

Figura 93: Mensaje del botón dentro del archivo donde se alojan las cadenas de texto.

Debemos puntualizar que en los apartados BackgroudTint y Text podría ponerse

directamente tanto el color como el texto que se desea respectivamente, pues Android

Studio permite esta acción sin ningún problema. No obstante, se han separado en

archivos aparte porque seguramente los desarrolladores de esta aplicación saben que es

una opción mucho más acertada en caso de que en un futuro quisieran realizar cambios

en la aplicación o deseasen que se tradujese a más idiomas.

Lo mismo sucede con la fuente: si accedemos a la carpeta assets podemos ver que ahí se

encuentra la carpeta que contiene los tipos de letra empleados.

Figura 94: Carpeta con los tipos de letra.


Aunque hemos encontrado numerosos comentarios para otros desarrolladores, no

encontramos ni un solo comentario destinado a los traductores:

86

Figura 95: Comentarios para los desarrolladores.

Figura 96: Comentarios para los desarrolladores.

Con respecto a esto, cabe decir que como bien nos ha podido confirmar la persona que

nos ha proporcionado esta aplicación, los desarrolladores sabían perfectamente desde

antes de comenzar a diseñar esta aplicación que se iba a traducir al euskera.


Además de no haber comentarios que sirvan de contexto a los traductores, tampoco hay

ningún tipo de glosario, directriz o guía de estilo en la que estos puedan apoyarse.

87

A pesar de que mi conocimiento sobre el euskera es prácticamente nulo, considero que

podría haber sido apropiado añadir comentarios o directrices para los traductores, pues

siempre es oportuno contar con mayor contexto.


No hemos encontrado ningún tipo de procedimiento empleado para diferenciar aquellas

cadenas de texto que efectivamente requieren traducción de las que no deben traducirse

porque quizá solo sirvan internamente a la propia aplicación y no se muestren al

usuario.


Antes de determinar si el nombre de las variables es o no significativo, consideramos

oportuno añadir que, como bien se ha comentado en el apartado del presente trabajo

destinado a recoger una serie de conocimientos básicos de programación, Java es un

lenguaje de programación tipado, de forma que las variables deberán declararse con un

tipo y tendrán un nombre de identificador.

Una vez explicado esto, podemos concluir que los desarrolladores han dado nombres

bastante significativos a las variables de esta aplicación, de manera que es posible intuir

para qué se están usando.

Con el fin de demostrar esto, hemos accedido a otro archivo dentro de la carpeta java,

concretamente al archivo que tiene por nombre WelcomeActivity. Basta con mirar al

principio del archivo, donde habitualmente se declaran las variables, para ver unas

cuantas variables cuyos nombres resultan bastante intuitivos:

Figura 97: Declaración de variables.

88

Como podemos observar, algunos nombres de variables son “btonSkip” “btnNext”,

“btonChangeLanguage”, “CurrentPage”, “layouts” o “availableLanguages”.


Respecto a la codificación de la aplicación, simplemente basta con mencionar que,

como bien podemos ver en el archivo “AndroidManifest.xml”, se ha empleado la

codificación UTF-8.

Figura 98: Codificación en el manifiesto de Android.

Por otra parte, dado que esta aplicación no está traducida a idiomas cuya dirección de

escritura sea de derecha a izquierda, no sería necesario hacer apuntes sobre la

bidireccionalidad.


Tras analizar de principio a fin tanto el archivo donde están las cadenas de texto, como

cada uno de los archivos que contiene la carpeta main, no hemos encontrado ningún

placeholder. No obstante, esto no nos resulta sorprendente, pues al tratarse de una

aplicación muy sencilla que, como bien se ha explicado, consiste en una serie de

acertijos que hay que ir adivinando, es bastante probable que los desarrolladores no

hayan considerado necesario su uso.


La aplicación no tiene ningún tipo de manual de ayuda, guía de uso o capturas de

pantalla explicativas. No obstante, se trata de una aplicación tremendamente intuitiva y

sencilla de emplear, por lo que se entiende que no sería necesaria la presencia de estos

elementos.

89

Por otra parte, sí podemos encontrar un vídeo que tampoco está incrustado en el código

fuente, sino que se aloja en una carpeta aparte a la que se llama desde el código.

Si clicamos sobre el nombre del archivo del vídeo, Android Studio nos indica que este

está alojado en la carpeta raw, a su vez dentro de la carpeta res (resources):

Figura 99: llamada al vídeo desde el código fuente.

Este video está tanto en español como en euskera, pero no tiene subtítulos. A pesar de

estar grabado en ambos idiomas, cabe decir que hemos realizado la prueba y si

cambiamos el idioma de la aplicación al euskera, el vídeo se sigue reproduciendo en

español, cosa que no sucede al reproducir el vídeo directamente desde el archivo alojado

en la carpeta raw.


En cuanto a los iconos, imágenes, etc. no contienen texto incrustado (salvo el logo de la

aplicación) y son muy simples e intuitivos:

Figura 100: Iconos presentes en la aplicación.

90


Sobre la selección del idioma de la aplicación, cabe decir que en la pantalla de inicio

encontramos un botón bastante intuitivo con el que podemos elegir el idioma en el que

queremos visualizar la aplicación. Además, se ha mantenido el nombre del idioma en el

propio.

Figuras 101 y 102: Selección del idioma en la pantalla de inicio de la aplicación.

No obstante, antes de concluir el análisis es importante añadir que la elección de un

botón con texto para realizar el cambio de idioma no sería igualmente satisfactoria en

caso de que la aplicación estuviera traducida a otros idiomas.

En este caso concreto entendemos que se ha hecho así porque aquellas personas que van

a emplear la aplicación en euskera también hablan español. Sin embargo, si por ejemplo

la aplicación también se tradujera al inglés, sería necesario traducir el texto del botón o

utilizar otro tipo de botón que no contuviese texto.

91

11.5. Aplicación móvil GnuCash para Android:

GNU CASH PARA ANDROID


Aplicación móvil.

Lenguaje de programación. Java.



Separados.

¿Hay comentarios para los desarrolladores? Sí.



Sí.

¿Hay glosarios, guías de estilo, etc.? En Crowdin.


Sí

¿Nombres de las variables significativos? Sí




No.


No.



No.

¿Nombre de los idiomas en idioma origen? No.


Sí.

92


GnuCash para Android se presenta en el Google Play Store como una aplicación móvil

complementaria al programa de ordenador GnuCash previamente analizado. No

obstante, también en Google Play Store se aclara que no es posible sincronizar esta

aplicación con el ordenador.

Figuras 103 y 104: Descripción de la aplicación y aclaración sobre la misma.

Al igual que la aplicación móvil anterior, está también está programada en Java.


mismo?

Para comprobar si las cadenas de texto están separadas del código fuente, hemos

acudido a la carpeta java y llegado hasta la carpeta llamada ui (user interface), donde

entendemos que necesariamente va a haber cadenas de texto que se muestren al usuario.

Una vez en esa carpeta, hemos elegido la carpeta settings y accedido a la carpeta dialog,

cuyo nombre nos hace intuir -una vez más- que va a contener cadenas de texto.

Así pues, en la carpeta dialog hemos podido comprobar que, tal y como sucedía en la

aplicación anterior, se llama a las cadenas de texto desde el código fuente y se indica la

ruta donde están alojadas dichas cadenas.

93

Figura 105: llamada a las cadenas de texto desde el código fuente.

Si ahora acudimos a la carpeta de recursos (res), donde a su vez está la carpeta en la que

se aloja el archivo que contiene las cadenas de texto (res>values>strings), podemos

buscar los identificadores de esas cadenas y comprobar que efectivamente están ahí.

Figura 106: Archivo xml con las cadenas de texto.

94

Figura 107: Cadena con identificador title_confirm_delete.



Al igual que las cadenas de texto, hemos podido comprobar que los colores tampoco

están incrustados en el código fuente.

Esto puede intuirse con el simple hecho de ver que existe un archivo dentro de la

carpeta values (res>values) que recibe el nombre de colors.xml. No obstante, para

realizar una demostración más rigurosa, vamos a realizar la misma práctica que en la

aplicación anterior:

Si abrimos uno de los archivo con extensión .java, podemos ver cómo se está llamando

a los colores que están alojados en una carpeta específica. Así pues, si por ejemplo

accedemos al archivo TransactionsActivity.java, vemos que en una determinada línea de

código se está realizando una llamada a los colores debit_red y credit_green, los cuales

están alojados en la carpeta resources (R):

95

Figura 108: Llamada a los colores desde el código fuente.

Si accedemos a la carpeta en la que están alojados dichos colores, (res> values> colors.

xml), vemos que, al igual que en la aplicación «Pamplona Negra» estos se han

expresado a través del método hexadecimal (#c11b17 y #4cc552).

Figura 109: Archivo donde se alojan los colores de la aplicación.

Lo mismo sucede con las plantillas: estas cuentan con una carpeta propia que recibe el

nombre de layout, donde encontramos gran cantidad de ellas en formato .xml.

Por ejemplo, una de ellas tiene por nombre dialog_account_delete.xml.

96

Figura 110: Layout “dialog_account_delete”.

Si buscamos el nombre de la misma con el atajo de teclado Control + Shift+ F que nos

permite buscar en ruta de acceso en todo el proyecto que hemos importado a Android

Studio, la búsqueda nos lleva al archivo DeleteAccountDialogFragment.java, desde el

cual se está llamado a esta plantilla para establecer la vista.

Figura 111: Búsqueda en Android Studio

97

Figura 112: La plantilla con nombre dialog_account_delete está alojada en la carpeta layout.

Así pues, podemos concluir que al igual que las cadenas de texto, ni colores ni

plantillas están incrustados en el código fuente.


Con respecto a los comentarios para traductores, nos hemos centrado en analizar el

archivo donde se encuentran las cadenas de texto originales, y aquel que se ha creado

específicamente para alojar las cadenas de texto en español de España. No obstante,

podría bastar con analizar el primero.

Una vez analizado en profundidad el primer archivo, hemos podido comprobar que

existen varios comentarios destinados a los traductores, aunque estos son bastante

escasos. En total hay seis comentarios en todo el archivo:

Figura 113: comentario para traductores.


98


Estos comentarios hacen referencia a aspectos como el límite de caracteres, la extensión

del archivo, o a un mínimo contexto relacionado con la finalidad de dichas cadenas.

Por otro lado –y como ya viene siendo habitual-, el número de comentarios destinados a

otros desarrolladores es tremendamente superior. A continuación se muestran algunos

ejemplos:

Figura 116: Comentario para desarrolladores.

99



Como se puede apreciar en las figuras de este apartado, para los comentarios destinados

a los traductores se ha empleado la sintaxis de comentarios propia de xml, formato de

los archivos donde se alojan las cadenas de texto.

Por otra parte, los comentarios de los desarrolladores se han marcado siguiendo la

sintaxis de comentarios propia de Java descrita previamente a lo largo de este trabajo.

100


A pesar de que la aplicación en sí no contiene ningún glosario o recurso adicional para

los traductores, cabe decir que en la página en la que podemos descargar el proyecto

(http://codinguser.github.io/gnucash-android/) se facilita una dirección web que nos

lleva a un blog con pautas de traducción. Sin embargo, esta entrada se actualizó por

última vez en 2012 y contiene información muy escueta.

Por otra parte, en de la dirección web de Github que se corresponde con el repositorio

de la aplicación móvil existe un apartado dirigido a aquellas personas que quieran

contribuir al mismo:

Figura 119: Apartado de contribución de GnuCash para Android.

Con respecto a la guía de contribución a la que se hace mención en la figura anterior,

cabe decir que esta está fundamentalmente destinada a los desarrolladores, ya que se

dan pautas relacionadas con la escritura de código fuente. De hecho, una de las pautas

hace referencia a la importancia de utilizar comentarios. No obstante, no se está

refiriendo a comentarios para los traductores, sino a comentarios destinados a otros

desarrolladores:

Figura 120: Se recomienda a los desarrolladores que anoten comentarios para que otros desarrolladores

entiendan su trabajo con mayor facilidad.

En cuanto a las traducciones, esta aplicación utiliza la plataforma de gestión de

localización que recibe el nombre de Crowdin. En esta plataforma encontramos tanto la

descripción de la aplicación en Google Play Store como las cadenas de texto que

requieren traducción a distintos idiomas. Además, muestra en qué porcentaje se sitúa el

proceso de traducción a cada idioma.

http://codinguser.github.io/gnucash-android/

101

En el caso concreto de esta aplicación, se emplea la desaconsejada práctica de utilizar

banderas para hacer referencia a los distintos idiomas a los que se está traduciendo:

Figura 121: Banderas y porcentajes de traducción a cada idioma.

Tras interactuar con esta plataforma de gestión de localizaciones, hemos comprobado

que presenta una interfaz bastante sencilla e intuitiva y que en parte puede recordar a la

de Google Translator Toolkit.

Cuando seleccionamos los distintos fragmentos que componen el texto original, se

habilita el cuadro donde podemos introducir la traducción de los mismos.

102

Figura 122: Área de trabajo de Crowdin.

Como bien decíamos antes, dentro de los recursos no se proporciona ningún glosario o

similares, sin embargo, al seleccionar el segmento que se desea traducir, esta plataforma

ofrece tanto la sugerencia de traducción aportada por otros usuarios, como una

sugerencia proporcionada por el traductor automático de Microsoft. Además, también

permite realizar búsquedas en la memoria de traducción o consultar cómo se ha

traducido un determinado segmento a otros idiomas:

Figura 123: Traducción del segmento a otros idiomas.

103

Figura 124: Podemos buscar en la memoria de traducción.

Figura 125: Sugerencias de otros usuarios y del traductor automático de Microsoft.

104


Además de haberse extraído en un archivo específico, las cadenas de texto también se

han catalogado como traducibles o no traducibles, pues hemos podido comprobar que

dentro del proyecto existe un archivo donde están almacenadas las cadenas que

supuestamente, y como el nombre del archivo indica, no se deben traducir:

(res>values>donottranslate.xml).

Figura 126: Archivo que contiene las cadenas de texto que no se deben traducir.

Por otro lado, también en la misma carpeta encontramos el archivo strings.xml, que

contiene las cadenas que efectivamente requieren traducción. De hecho, estas cadenas

se corresponden con aquellas que están traducidas a muchos otros idiomas:

Figura 127: Archivo que contiene las cadenas de texto traducibles.

105


Una vez explicadas las pautas que se siguen Java para dar nombre a las variables,

podemos pasar a determinar si por lo general los nombres de las variables de los

archivos con extensión .java de esta aplicación resultan intuitivos o no.

Figura 128: Variables.

En esta figura podemos ver que la primera variable es de tipo String –es decir, contiene

una cadena de texto- y recibe el nombre de mOriginAccountUID. De este nombre,

podemos deducir que tiene relación con el identificador de usuario de la cuenta de

origen.

Si observamos las siguietnes cuatro líneas de código que corresponden con cuatro

variables, todas ellas son de tipo RadioButton y tienen nombres diferentes, todos ellos

bastante intuitivos.

A pesar de que aquí tan solo se muestran un par de ejemplos, tras el minucioso análisis

del proyecto en su totalidad podemos afirmar que por lo general los nombres de las

variables son significativos y transmiten información que puede resultar relevante.


Al igual que en la aplicación previamente analizada, si abrimos el manifiesto de

Android contenido en el proyecto de la aplicación, podemos ver que la codificación se

corresponde con UTF-8.

106

Figura 129: Codificación UTF-8.

Esto también puede comprobarse en el archivo de configuración build.gradle:

Figura 130: El proyecto emplea la codificación UTF-8.


En cuanto a los placeholders, hemos encontrado de dos tipos: por un lado encontramos

el símbolo %d, que hace referencia a los plurales (cantidad de un determinado

elemento), y por otro lado encontramos placeholders que hacen referencia a todo un

elemento o cadena de texto.

Figura 131: Referencia a todo un elemento o cadena de texto.

107

Figura 132.: Referencia a todo un elemento o cadena de texto.

Tras un examen exhaustivo, no hemos encontrado ni un solo comentario referido a estos

placeholders. No obstante, si contamos con experiencia previa en la localización

sabremos que el conjunto de caracteres d% se suele emplear para indicar plurales.

Además, aunque no supiésemos esto, basta con analizar las etiquetas del archivo xml en

las que se indica que son plurales o atender a los atributos y sus valores (item quantity):

Figura 133: Referencia a plurales.

108

Figura 134: Item quantity.


La aplicación cuenta con un apartado de ayuda y sugerencias al que se puede acceder a

través del menú desplegable situado en la esquina superior izquierda. No obstante, la

información de este apartado solo se muestra en inglés.

Figura 135: La ayuda se muestra en inglés.

109

A pesar de que contamos con este apartado de ayuda como guía para utilizar la

aplicación, no hemos encontrado ningún tutorial en formato vídeo ni capturas que

requieran localización.


Aparentemente ningún icono contiene texto incrustado. Además, por lo general son

iconos bastante sencillos.

Figura 136: Iconos.

110

Figura 137: Iconos.


Por último, es importante decir que tras una minuciosa búsqueda dentro del menú y los

distintos ajustes del mismo, no hemos logrado encontrar una opción que nos permita

cambiar el idioma dentro de la propia aplicación.

Cuando buscamos la aplicación en el Google Play Store, esta se descarga de manera

automática en español y no permite elegir ningún otro idioma a pesar de que sabemos

con certeza que esta aplicación está disponible en más idiomas.

Esto supone un error bastante grave y genera un problema de inaccesibilidad, pues

aunque en realidad existiese una forma relativamente rápida de cambiar el idioma de la

aplicación, aparentemente no es una opción lo suficientemente visible como para que

cualquier usuario la localice con un solo vistazo. Este factor explica además que no

hayamos podido comprobar la bidireccionalidad.

110

11.6. Página web Electronjs.org:

Para concluir este estudio vamos a analizar dos páginas webs:

ELECTRONJS.ORG


Página web.

Lenguaje de programación. JavaScript.



Separados.


Sí.



Sí.

¿Hay glosarios, guías de estilo, etc.? Sí, en Crowdin.


Sí.





No.


Sí.



No.


Sí.


Sí

111


Tal y como se describe en su propio sitio web, Electron es « un framework para crear

aplicaciones nativas con tecnologías web como JavaScript, HTML y CSS». Además, es

de código abierto y es compatible tanto con Windows, como con Linux y Mac. No

obstante, nosotros no vamos a analizar el framework en sí, sino que nos vamos a centrar

en analizar su sitio web.

Cuando accedemos al código fuente desde la página web haciendo clic en el icono de

Github situado en la esquina superior derecha, se nos muestran varias opciones.

Nosotros hemos elegido analizar el sitio web de Electron, por lo que hemos descargado

el proyecto que se indica en la siguiente figura:

Figura 138: repositorio de la página web de Electron.

No obstante, existe junto a este un segundo repositorio dedicado exclusivamente a la

internacionalización y traducción de Electronjs, y dado que la internacionalización es

parte fundamental del tema que ocupa el presente trabajo de investigación, hemos

decidido analizar también dicha rama del proyecto. De hecho, como vamos a ver a lo

largo del presente análisis, la propia página web requiere en el código fuente la carpeta

en la que se alojan todos los archivos relacionados con la internacionalización de este

framework. Así pues, creemos necesario analizar ambas carpetas de manera conjunta.

112


mismo?

Para comprobar si las cadenas de texto están separadas del código fuente, lo primero

que es necesario saber es que hemos descubierto que dentro de la carpeta principal

destinada a la internacionalización de Electron (i18n-master) hay un archivo locale.yml

para cada idioma alojado dentro de la carpeta website que se encuentra en la carpeta del

idioma correspondiente y que a su vez se encuentra dentro de la carpeta content.

Figuras 139 y 140: archivo locale.yml para cada idioma.

Estos archivos locale.yml contienen todas las traducciones relacionadas con Electron

siguiendo un paradigma de almacenamiento llamado par clave-valor, quizá más

conocido como key-value pair en inglés.

“A key-value pair (KVP) is a set of two linked data items: a key, which is a unique identifier for

some item of data, and the value, which is either the data that is identified or a pointer to the

location of that data. Key-value pairs are frequently used in lookup tables, hash tables and

configuration files”. (Rouse, 2008)

En definitiva, en estos archivos locale.yml se guardan las traducciones proporcionadas

por los voluntarios en Crowdin para las cadenas de texto de la página web de Electronjs

y otras cadenas de texto que constituyen el framework.

113

Figura 141: archivo con las traducciones en español. Pares clave-valor.

Una vez encontrados los archivos que contienen las cadenas de texto en los distintos

idiomas a los que la página web está traducida, hemos querido comprobar que

efectivamente a estos archivos locale.yml se les llama desde el código, pues recordemos

que no están incrustados en el mismo, sino que constituyen archivos independientes.

Tras un minucioso análisis, hemos hallado el archivo i18n.js, fundamental para realizar

esta comprobación. Este archivo se aloja en la carpeta principal de la página web

(Electronjs.org-Master) y no en la carpeta i18n-master.

Figura 142: Electronjs.org-Master>lib.

114

Al abrir este archivo nos encontramos la función que se muestra en la siguiente figura:

Figura 143.

De manera muy simplificada, lo que hemos entendido tras estudiar detenidamente esta

función y leer el comentario que la acompaña es que, lo primero a lo que se hace

referencia es a locales, que en este caso no se trata de una archivo donde se alojan

cadenas de texto traducidas, sino de un archivo totalmente diferente que está alojado

dentro de la carpeta i18n-master (i18n-master > lib) y que, de manera muy resumida y

sin entrar en detalles demasiado técnicos, podemos decir que se encarga de captar el

idioma en el que el usuario desea que se muestre el sitio web cuando este lo selecciona.

115

Figura 144.

Una vez se recorre este archivo locales.js y se detecta en qué idioma se debe mostrar el

sitio web, pasa a recorrerse los pares clave-valor que corresponden al idioma

seleccionado para asignarles un valor, que en este caso es la traducción correspondiente.

Para explicar cómo se lleva a cabo esta asignación de valores (traducciones) a las

distintas claves, nos vamos a centrar ahora en la siguiente parte de la función:

Figura 145.

En la parte señalada en rojo (figura 145) se muestra cómo la función comprueba si la

clave (deepKey) y sus correspondientes valores están en el archivo traducido alojado en

la carpeta content (Ejemplo: i18n-master>content>es-ES>website), para que en caso de

que no sea así, tome los valores que faltan de websiteStrings, que es el nombre que se ha

asignado en la declaración de variables al archivo locale.yml donde se encuentran las

cadenas de texto en inglés, idioma original en el que se ha desarrollado la página web.

Esto explica que encontremos oraciones y términos en inglés cuando elegimos que la

página se muestre en español, pues al no haber traducciones para esas cadenas –o lo que

es lo mismo, al no haber valores asignados a esas claves- en el archivo donde se alojan

las cadenas de texto traducidas al idioma seleccionado por el usuario, esta función hace

que a esas claves que no tienen un valor asignado se les asigne el valor «por defecto», es

decir, el valor que tienen esas claves en el archivo donde se alojan las cadenas de texto

en el idioma original (inglés estadounidense).

116

Figura 146: Al seleccionar el español, algunos fragmentos se mantienen en inglés.

Así pues, como hemos podido demostrar, las cadenas de texto efectivamente se alojan

en archivos independientes y separados del código fuente, desde donde se realiza la

llamada a las mismas.



Al igual que las cadenas de texto, los estilos de la página web también están separados

del código fuente y constituyen archivos independientes. Al tratarse de una página web,

esto necesariamente implica que los colores y fuentes empleados también estén

separados, pues al fin y al cabo ese es uno de los objetivos fundamentales de las hojas

css.

Basta con que abramos la carpeta de Electronjs-master para que veamos una carpeta

que recibe el nombre de styles.

Figura 147: Carpeta styles.

117

Dentro de esta carpeta, encontramos numerosos archivos, cada uno de los cuales

constituye un estilo diferente (figura xx):

Figura 148: hojas de estilos.

Como podemos ver, la extensión de estos archivos no se corresponde con la extensión

habitual de las hojas de estilo (.css). La razón de esto se debe a que las hojas de estilo de

esta página web se han creado con SASS.

SASS (Syntactically Awesome Style Sheets) es un preprocesador del que Villacampa

(2015) afirma lo siguiente:

« […] permite trabajar mucho más rápido en la creación de código con la posibilidad de crear

funciones que realicen ciertas operaciones matemáticas y reutilizar código gracias a los mixins,

variables que nos permiten guardar valores».

Además, tal y como explica este mismo autor, dentro de SASS existen dos extensiones

diferentes, de manera que puede generar archivos con extensión .sass y archivos con

extensión .scss.

El formato .sass fue el primero en surgir, y se trata de un formato que aporta facilidades

entre las que se incluyen no tener que usar punto y coma o llaves. En cuanto al segundo

118

formato (.scss), el cual se corresponde con el formato de los archivos de los que se ha

hablado en el presente análisis, permite utilizar llaves e incorporar código de CSS

clásico. En definitiva, SASS hace más fácil crear hojas de estilos. (Villacampa 2015).

Así pues, al llevar a cabo la compilación, los archivos .scss se transforman en archivos

con extensión .css, que es lo que realmente puede interpretar el navegador. Sin

embargo, no todos estos archivos se van a compilar en .css, pues como podemos ver,

todos ellos salvo el último (index.scss) tienen delante de su nombre un guion bajo. Este

guion nos indica que estos archivos no se van a compilar en .css. La razón de esto es

que si todos generasen el correspondiente archivo .css se producirían duplicaciones, ya

que a pesar de que cada estilo constituye un archivo independiente, todos ellos se

incluyen en el archivo index.scss (figura 149), que como bien hemos dicho, es el único

que va a generar un archivo .css.

Figura 149: Todos los estilos se importan a index.scss

A continuación, desde el archivo head.html se hace referencia a la hoja .css generada:

Figura 150.

119


Una vez más se da la situación en la que, mientras encontramos numerosos comentarios

destinados a los desarrolladores, no es posible hallar un solo comentario que tenga

como objetivo proporcionar información de cualquier índole a los traductores.

Figura 151: comentarios para los desarrolladores.

Figura 152: comentarios para los desarrolladores.

120


Para la traducción de su contenido, Electron utiliza la plataforma de gestión de

localización Crowdin, donde se han subido todas las cadenas de texto del framework

que requieren traducción, incluidas las que se muestran en la página web de Electron.

Así pues, tal y como ya hemos explicado en el análisis de la aplicación móvil GnuCash,

que también utiliza esta misma plataforma, se ofrece a la persona que está traduciendo

la posibilidad de acceder a una memoria de traducción –cuya calidad no siempre se

puede catalogar como buena-, así como al fragmento traducido a otros idiomas.

Un aspecto que no se ha comentado previamente es que Crowdin permite votar entre

opciones en caso de varios usuarios hayan aportado traducciones:

Figura 153: Crowdin permite votar entre posibles traducciones.


Puesto que, como se ha indicado previamente, Electron utiliza Crowdin como

plataforma de gestión de localización donde los usuarios pueden contribuir a la

traducción tanto del framework en sí como de la página web, entendemos que las

cadenas traducibes son todas aquellas que están subidas a dicha plataforma y que por

tanto no sería necesaria una distinción entre aquellas cadenas que requieren traducción y

aquellas que no.

121


En el lenguaje de programación JavaScript las variables se declaran mediante la palabra

var o cons (AA.VV). Además, al ser un lenguaje no tipado, no es necesario declarar su

tipo.

Una vez sabemos esto, podemos proceder a buscar variables con el fin de determinar si

su nombre resulta intuitivo o por el contrario es un tanto enigmático.

Si observamos las siguientes figuras (154 y 155), podemos ver que nombres como path,

walk, flat, getProp o dates resultan bastante intuitivos. No obstante, también nos

encontramos con nombres como chai o fs que a primera vista no resultan del todo

signiticativos. No obstante, es posible que sean nombres de archivos.

Figura 154.

Figura 155.


Si echamos un vistazo al archivo de configuración del proyecto (starred_apps.json),

podemos ver que la codificación empleada es UTF-8.

122

Figura 156: Se ha empleado la codificación UTF-8 para el proyecto.

En lo referente a la bidireccionalidad, a pesar de se ha iniciado la tradución de la página

web al árabe, esta traduccón no va lo suficientemente avanzada (3%) como para poder

comprobar si existen deficiencias en este aspecto.


En la página inicial del sitio web de Electron se realiza una presentación de este

framework y se ofrece la posibilidad de visualizar un vídeo que complementa a dicha

presentación.

Si hacemos clic en el botón marcado en rojo en la figura 157, la página web nos lleva a

un vídeo de Youtube.

Figura 157: Es posible visualizar un vídeo en el que se explica en qué consiste Electron.

Tras ver el vídeo, podemos concluir que este no contiene capturas de pantalla o

imágenes que requieran localización, pues simplemente utiliza iconos muy sencillos. No

obstane, sí sería necesario grabar la voz superpuesta en los distintos idiomas en los que

se quiera ofrecer una traducción de la web o el framework.

123

Figura 158: El vídeo se aloja en Youtube.

Además, también hemos podido comprobar que la guía de usuario de este framework,

en la que se mezclan fragmentos traducidos al español y otros en inglés, tampoco

contiene capturas de pantalla que puedan servir de guía al usuario y que requieran

localización.


En cuanto a los iconos, imágenes y gráficos, a excepción de algunos logos, ninguno

contiene texto incrustado. A continuación se muestran algunos ejemplos, pues a pesar

de que nos gustaría incluir todas las imágenes, el número de las mismas es demasiado

elevado:

124

Figura 159: Iconos.


La selección del idioma en el que queremos visualizar el sitio web se lleva a cabo en el

botón que se encuentra en la esquina superior derecha de la página de inicio.

En lo referido a este botón, es importante añadir que se trata de un botón que no resulta

demasiado intuitivo, pues en él tan solo aparece el idioma en el que la página se está

mostrando en ese mismo momento.

Como ya se ha comentado en la aplicación «Pamplona Negra», colocar texto en un

botón con esta utilidad no siempre es acertado. Además, resulta muy poco llamativo

dentro del menú en el que se encuentra, por lo que considero que podría emplearse un

botón que resulte más familiar y reconocible para los usuarios.

125

Figura 160: Botón para la selección del idioma.

Si hacemos clic sobre este botón, no solo accedemos a una nueva página donde

podemos seleccionar un determinado idioma, sino que a la derecha de cada idioma se

nos presenta la opción de contribuir en la traducción a ese idioma, así como una barra

de progreso que muestra el avance de dicha traducción.

Figura 161: progreso de la traducción a distintos idiomas.

Para concluir, cabe añadir que cada idioma aparece tanto en el idioma propio como en

inglés (figura 162):

126

Figura 162.

127

11.7. Página web Phalcon.com:

PHALCON.COM


Página web

Lenguaje de programación. PHP.



Separados.


Sí.



Sí.

¿Hay glosarios, guías de estilo, etc.? En Crowdin.


Sí.





No.


Sí.



Sí.


No.


Sí.

128


Al igual que Electron, Phalcon también es un framework de código abierto para

desarrollar aplicaciones. No obstante, en este caso, en el apartado «documentación» de

en la página web que aquí vamos a analizar, se especifica que es para PHP y está escrito

como una extensión en C.

Figura 163: Descripción de Phalcon.


mismo?

Al igual que en todos los proyectos analizados, en la página web de Phalcon las cadenas

de texto están separadas del código fuente, de manera que a cada idioma le corresponde

un archivo independiente que contiene las cadenas de texto en ese idioma. Al igual que

sucedía con la página web anterior, estos archivos contienen las cadenas de texto

traducidas siguiendo el paradigma de pares clave-valor; dichos archivos se alojan en la

carpeta languages, que a su vez está dentro de la carpeta storage:

Fig. 164: Archivos donde se alojan las cadenas.

129

Figura 165: Archivo que almacena las cadenas de texto en inglés (idioma original).

Figura 166: Archivo que almacena las cadenas de texto en español.

130

Figura 167: Archivo que almacena las cadenas de texto en francés.

Con respecto a esta última figura en la que se muestra el archivo donde se almacenan las

cadenas traducidas al francés, cabe añadir que basta con echar un vistazo rápido para

comprobar que muchas de ellas no están traducidas, algo que también se refleja en la

página web, donde se mezcla el inglés y el francés incluso en un mismo apartado:

Figura 168: Fragmentos sin traducir al francés.

Así, pues, al no estar incrustados en el código fuente, se llama a las cadenas desde el

mismo, más concretamente desde el archivo locale.php:

131

Figura 169: llamada a los archivos que contienen las cadenas de texto.



Entendemos que, al igual que las cadenas de texto, los estilos también están separados

del código fuente y no incrustados en el mismo, pues dentro de la carpeta public

encontramos una carpeta que recibe el nombre de css, donde como su nombre indica,

encontramos archivos con extensión .css. Además, en esta última carpeta también

encontramos otra con el nombre src, donde al igual que en Electron, podemos encontrar

tanto archivos sass como los correspondientes archivos css que se generan a partir de

los primeros.

Por otra parte, si abrimos el archivo styles.css podemos comprobar cómo cada elemento

(encabezado, distintas barras de desplazamiento, etc.) tiene un determinado tamaño de

fuente y un color asignado.

132

Figura 170: Fuentes y colores de las distintas partes.


En lo que respecta a los comentarios, como viene siendo ya muy frecuente entre los

análisis que hemos realizado, en este proyecto encontramos una ingente cantidad de

comentarios destinados a los desarrolladores, lo que contrasta de forma muy destacada

con el número de comentarios destinados a los traductores, que en este caso es cero.


133


Figura 173: Comentarios para desarrolladores.

134


Otra de las características que Phalcon comparte con el proyecto Electron es que, al

igual que este, Phalcon también se sirve de Crowdin como plataforma de gestión de

localización donde los usuarios que deseen colaborar pueden proporcionar traducciones

a numersos idiomas de las cadenas de texto que constituyen tanto la página web como el

propio framework:

Figura 174: Traducción colaborativa.

Por este mismo hecho, como ya se ha explicado en anteriores análisis, los usuarios que

usan Crowdin para la traducción de la web de Phalcon se pueden valer de una memoria

de traducción -cuya calidad no vamos a abordar en el presente trabajo-, así como de

sugerencias de otros usuarios y del traductor automático de Microsoft. Además, también

pueden consultar cómo se ha traducido ese segmento a otros idiomas.


Entendemos que, al servirse de Crowdin para la traducción de las cadenas de texto,

todas aquellas cadenas que están en la plataforma requieren traducción, por lo que

nuevamente no sería necesario hacer una distinción entre las cadenas que requieren

traducción y las que no.


En PHP, lenguaje en el que se ha desarrollado la página web de Phalcon, las variables se

declaran a partir del símbolo el dólar ($). Además, tal y como se indica en la página web

oficial de php, los nombres de las variables tienen que empezar con un una letra o un

guión bajo (_), y a pesar de que pueden contener números, estos no pueden ser el primer

carácter del nombre de la variable. Si hacemos memoria, podremos comprobar que estas

pautas coinciden con las expuestas en el apartado de programación que forma parte de

la primera sección del presente trabajo de investigación.

135

Una vez conocemos esta información, hemos procedido a buscar distintas variables

entre los archivos php.

Tras realizar un análisis relativamente minucioso, podemos decir que los nombres de la

mayoría de ellas, como puede ser el caso de $lang, $languages, $frontEnd, $config o

$default (figuras 175 y 176), resultan bastante intuitivos. No obstante, como bien se ha

comentado en análisis anteriores, siempre habrá excepciones de variables cuyo nombre

resulte un tanto intricado.

Figura 175: En php las variables se declaran a partir del símbolo del dólar.

Figura 176: Variables con nombres intuitivos.


Si echamos un vistazo al archivo htacces, que como bien se indica en la página web de

Apache se corresponde con el archivo de configuración del servidor web que en este

caso aloja Phalcon.com, podemos comprobar que la codificación empleada se

corresponde con UTF-8.

136

Figura 177: Se ha empleado la codificación UTF-8 de Unicode.

Por otra parte, aunque hemos podido comprobar que gracias a Unicode la página web se

muestra perfectamente en idiomas como el chino, el coreano o el griego, esta página

web no está traducida a idiomas como el árabe o el hebreo, por lo que no vamos a hacer

apuntes sobre el aspecto de la bidireccionalidad.


El motivo de que en la tabla resumen del análisis de esta web hayamos indicado que no

hay placeholders, es que aunque hemos detectado la presencia de varios, no ha sido en

los archivos donde se encuentran las cadenas de texto.

Tal y como hemos podido observar, en este proyecto se hace uso de placeholders para

hacer referencia a una ruta en cual que varía uno de sus elementos. Un ejemplo claro de

esto es el caso de la ruta que se muestra en la figura 169 mostrada previamente y que

coincide con la ruta donde se alojan los distintos archivos que contienen las cadenas de

texto en el idioma correspondiente:

Figura 178: Empleo de placeholders en la ruta de acceso de varios archivos.

137

En este caso, el placeholder %s se emplea para hacer referencia a que el idioma variará

y por tanto variará también el nombre de la carpeta.


Si pasamos ahora a tratar el aspecto más audiovisual del proyecto, en la parte inferior de

la página de inicio encontramos un tutorial en formato vídeo que únicamente está en

inglés, algo que deja claro que la localización no se ha completado en absoluto.

Recordemos además que de este vídeo no solo habría que grabar una nueva voz

superpuesta que correspondiese al idioma en el que se esté mostrando la página, sino

que además también sería necesario hacer nuevas capturas de pantalla de todas las

imágenes que se muestran en el vídeo para que dichas capturas se correspondan con la

interfaz en el idioma seleccionado por el usuario.

Figura 179: Vídeo que requiere localización.


En cuanto a los iconos e imágenes, ninguno de ellos contiene texto incrustado. Además,

son imágenes sencillas e iconos intuitivos y en absoluto complejos.

138

Figura 180: Iconos empleados en Phalcon.

Por lo que podemos ver hasta aquí, en todos los proyectos esta ha sido una de las pocas

pautas recomendables en la internacionalización que se ha seguido meticulosamente.


En lo que respecta a la selección del idioma desde la página de inicio del sitio web, esta

se lleva a cabo en un menú desplegable que aparece al clicar sobre un icono de una

bandera. Aunque considero que este botón puede resultar intuitivo, también creo que es

demasiado pequeño. A esto se suma el hecho de que una vez más se ha decidido

emplear banderas para representar los distintos idiomas, lo que puede llevar al rechazo

por parte de ciertos usuarios.

139

Figuras 181 y 182: Menú desplegable de idiomas.

Por otra parte, como bien podemos ver, no se ha seguido un criterio uniforme para

mostrar los nombres de los idiomas, ya que mientras que la mayoría de ellos está

simplemente en inglés, otros idiomas como el chino se muestran en el propio idioma, es

decir, en chino. Sin embargo, ni el coreano se muestra también en coreano, ni el japonés

en japonés, etc.

También hemos observado que el botón cambia de posición en función del idioma que

esté seleccionado, lo que probablemente se deba a que la extensión del texto que

también forma parte del menú superior va variando según el idioma.

Este cambio de posición de dicho botón supone un problema de inaccesibilidad, pues

puede provocar una gran confusión entre los usuarios.

Figura 183: En español el botón aparece debajo del texto del menú.

140

Fiura 184: En inglés el botón se muestra a la derecha del menú.

Por último, hemos descubierto algo que nos ha llamado la atención, pues si en lugar de

cambiar el idioma de la página web desde la página de inicio de la misma, lo

cambiamos desde el apartado de «Documentación», en este caso los idiomas sí se

muestran en el idioma original de cada uno:

Figura 185.

11.7.13. Errores:

Dada la gravedad de algunos de los errores que hemos observado a lo largo del análisis

de la página web de Phalcon, consideramos oportuno dedicar un apartado dedicado en

exclusiva a comentar un error en particular que nos parece especialmente grave:

Si echamos un nuevo vistazo a las figuras en las que aparecen todos los idiomas entre

los que los usuarios pueden elegir que se muestre la página web, comprobaremos que

141

las banderas no solo pueden suponer un rechazo entre ciertos usuarios, sino que además

no se han utilizado de manera correcta, lo que hace perder mucha credibilidad y

seriedad a una página web.

En la figura 181 observamos que para el armenio se ha utilizado la bandera de

Argentina, país donde evidentemente no se habla dicho idioma. Además, si echamos

también un vistazo a la figura 185, de nuevo la bandera de Argentina se ha utilizado

para representar un idioma con el que poco o nada tiene que ver y que en este caso es el

árabe –idioma al que en realidad no está traducida la página-.

Si ahora nos centramos en el vietnamita (Tiếng Việt), con este idioma se produce la

misma incoherencia, pues para su representación han utilizado dos banderas

completamente distintas en la figura 182, donde se usa la bandera de Vietnam y en la

figura 185, donde se usa la bandera de las Islas Vírgenes.

Este error no queda reducido a estos casos, sino que además, se ha utilizado la bandera

de Canadá para representar el catalán (figura 181), se han usado palabras distintas para

representar el chino en ambas figuras, se ha empleado la bandera de Surinam para

representar el serbio, etc.

Por último, para el danés, el ucraniano, el armenio, el danés o el kazajo ni si quiera ha

utilizado bandera (figuras 181 y 182), de manera que simplemente aparece el nombre de

los idiomas en inglés.

El resto de errores observados tiene relación con la traducción, pues como hemos dicho,

al seleccionar determinados idiomas estos aparecen mezclados con el inglés, y además,

si seleccionamos otros tantos como el árabe, el catalán, el húngaro, el rumano y muchos

otros más, la página permanece invariable en inglés, lo que nos da a entender que

todavía no existe una traducción para estos idiomas. En este caso, personalmente

considero que quizá sería oportuno quitar el idioma de entre la lista de opciones a elegir

hasta que las traducciones a ese idioma estuviesen más o menos completas, pues esto

crea falsas expectativas entre los usuarios.

11.8. Conclusiones del estudio:

A continuación se presentan las conclusiones que se han podido extraer tras el análisis

de estos seis proyectos diferentes:

En primer lugar cabe decir que, bajo mi punto de vista, el proyecto en el que más se ha

tenido en cuenta a los traductores se corresponde con la aplicación de escritorio

GnuCash. No obstante, incluso esta aplicación presenta deficiencias que hacen que no

pueda hablarse de una «aplicación localizada» como en muchas de las páginas webs o

presentaciones de los proyectos se asegura.

Resulta evidente que el factor más preocupante una vez concluido este análisis es que la

inclusión de comentarios destinados a los traductores es algo anecdótico. A excepción

de la aplicación de escritorio GnuCash, en la que como bien se ha comentado aparecen

142

casi un centenar de comentarios destinados a orientar o servir de ayuda a los

traductores, el resto de proyectos tan solo incluyen un par de comentarios de este tipo o

incluso ninguno.

En resumen: de los seis proyectos analizados, tres de ellos no cuentan con ningún

comentario para estos profesionales, dos apenas cuentan con un par, y tan solo una

aplicación cuenta con un número significativo de comentarios destinados a los

traductores.

Estas cifras contrastan de manera muy destacada con las correspondientes a la presencia

de comentarios destinados a otros desarrolladores, los cuales pueden encontrarse en

todos y cada uno de los seis proyectos y siempre de manera abundante.

A estos datos desoladores se suma el hecho de que tan solo la aplicación de escritorio

GnuCash ofrece recursos adicionales para los traductores como glosarios, guías de

estilo, etc. De entre los cinco proyectos restantes, mientras que dos no proporcionan ni

un solo recurso de este tipo, los otros tres se limitan a «ofrecer» los recursos incrustados

en la plataforma Crowdin, los cuales además presentan una fiabilidad y calidad dudosas.

En relación con esto, es importante atender a la ironía que se produce, pues la aplicación

que mayor número de comentarios para los traductores contiene es precisamente

aquella que además decide complementar dichos comentarios con recursos adicionales.

Si nos centramos en la accesibilidad, podemos afirmar de manera rotunda que todos los

proyectos presentan deficiencias en este aspecto: mientras que Notepad++ permite a los

usuarios cambiar de idioma de manera fácil e intuitiva a la vez que mantiene el nombre

de las distintas lenguas en el idioma original de cada una, el resto de proyectos

incumplen uno o incuso ambos factores.

Otro de los problemas de accesibilidad se relaciona con la localización de vídeos y

capturas de pantallas, una práctica que tan solo se ha realizado – de manera parcial- en

la aplicación de escritorio GnuCash y en la aplicación móvil desarrollada con motivo de

la Semana Negra de Pamplona –en la cual sin embargo no es posible escuchar el audio

del vídeo en euskera desde la propia aplicación-.

Otros errores muy frecuentes han sido algunos problemas de espacio y falta de

coherencia y uniformidad. No obstante, creemos que la razón de estos se debe a que la

traducción de estos proyectos utiliza el método ya mencionado del crowdsourcing, de

manera que no solo participan voluntarios que por lo general no son profesionales de la

traducción, sino que además llevar a cabo la coordinación del trabajo de un número tan

ingente de personas para conseguir un resultado uniforme y coherente no es una tarea

sencilla.

A favor de estos proyectos podemos decir que existe una serie de pautas recomendables

en el proceso de internacionalización que sí se han cumplido de manera generalizada.

Estas pautas se corresponden con: evitar que cadenas de texto, estilos, colores, fuentes,

etc. estén incrustados en el código fuente, así como que los iconos contengan texto

143

incrustado, extraer las cadenas de texto en archivos independientes y dar nombres

significativos a las variables.

Para finalizar, este estudio también nos ha permitido deducir la importancia de los

recursos económicos a la hora de llevar a cabo un proceso de internacionalización

exitoso: a pesar de que la mayoría de los proyectos analizados son de código abierto,

también hemos podido ver cómo en una aplicación cuyo código no es abierto tampoco

se siguen pautas demasiado favorables para los traductores. No obstante, esta aplicación

consiste en un proyecto muy discreto realizado por alumnos de un grado superior y de la

que no se han obtenido beneficios económicos.

Esto nos lleva a que en muchas ocasiones, las deficiencias o el poco tiempo invertido en

pensar en los traductores o localizadores como profesionales que forman parte

importante del proceso de creación de una aplicación o página web encuentran su

motivo en presupuestos económicos muy reducidos.

12. Sugerencias para el acercamiento de los localizadores o traductores

y los desarrolladores:

Como conclusión del presente trabajo, se ha decidido elaborar una pequeña lista en la

que, basándonos en las deficiencias observadas en el análisis previo, se recojan todos

aquellos aspectos que consideramos permitirían un acercamiento entre desarrolladores y

localizadores, y por consiguiente un mejor resultado en el proceso de localización de

productos de software y páginas web.

Resulta importante aclarar que las conclusiones extraídas del estudio que constituye la

segunda parte del presente trabajo de investigación nos han permitido comprobar de

primera mano la realidad de todas aquellas deficiencias que existen en el proceso de

adaptación de páginas web o aplicaciones, pues todas estas son reflejo fiel de las

carencias y problemas que efectivamente existen en dicho proceso y no suponen una

novedad en absoluto.

No obstante, la realización de un estudio como el aquí llevado a cabo también nos ha

permitido acotar aquellos aspectos que más atención requieren:

En primer lugar, como bien se recoge en las conclusiones del estudio realizado, las

deficiencias son mayores en aquellos aspectos relacionados con facilitar la labor de los

traductores. En contraste, estas deficiencias no son tan frecuentes a la hora de realizar

prácticas que favorecen a los propios desarrolladores (nombres significativos para las

variables, comentarios para otros desarrolladores, evitar el hard-coding, etc.).

De esto puede deducirse que existe entre los desarrolladores un gran problema de

empatía con los traductores. A este respecto, considero que parte de la solución a dicho

problema reside en la necesidad de que los primeros conozcan más a fondo en qué

consiste la labor de los segundos, pues solo así conseguirán entender por qué resulta tan

144

importante llevar a cabo prácticas como la inclusión de comentarios, aclaraciones,

glosarios, etc.

En relación con esto, considero que el desconocimiento de la labor del otro tiene como

resultado una imagen global difusa, pues al fin y al cabo, los desarrolladores dan mayor

importancia a realizar prácticas que resulten beneficiosas para ellos mismos. Sin

embargo, un conocimiento por su parte de la labor de los traductores les permitiría

entender que llevar a cabo prácticas que beneficien a estos últimos también supone un

beneficio indirecto para ellos mismos.

En cuanto a los traductores, personalmente considero que aprender algunos

conocimientos sobre programación tal y como se ha ido insistiendo a lo largo del

trabajo, no solo les permitiría conocer mejor la labor de sus compañeros desarrolladores

y conseguir tener una imagen global del proceso conjunto que forman la

internacionalización y la localización, sino que además, según Roturier (2015, 186), la

adquisición de estos conocimientos por parte de los traductores no implica en absoluto

competir con los desarrolladores, sino tratar de valerse por sí mismos sin tener que

recurrir a estos últimos.

A partir del estudio realizado también se ha podido corroborar el conocido hermetismo

que caracteriza a las empresas de desarrollo de software y páginas web, pues como bien

se ha comentado, uno de los motivos por los que nos hemos centrado en material de

código abierto reside en la negativa recibida a numerosas peticiones para que se nos

facilitase el código de algunos proyectos con fines exclusivamente didácticos.

Es precisamente este hermetismo uno de los elementos que más obstaculiza la labor de

los traductores, pues como bien se ha comentado a lo largo del presente documento, lo

más habitual es que estos profesionales apenas reciban unos cuantos archivos donde se

alojan las cadenas de texto extraídas y sin contexto alguno.

A pesar de que entendemos la importancia de la confidencialidad en un mundo tan

competitivo como el actual, también consideramos que sería recomendable que desde

estas empresas de desarrollo se reflexionase acerca de las prioridades, pues como es de

imaginar, todo aquello que se consigue en el intento de mantener el secretismo se pierde

en calidad de traducción.

En relación con esto, es importante que jamás se omita la fase de QA en la que detectan

fallos como rupturas del código o errores de traducción surgidos por la falta de

contexto. Con todo, en algunas ocasiones se prescinde del mismo por la elevada

cantidad de dinero que supone. Sin embargo, esta cantidad podría verse tremendamente

reducida si, como se comentaba en el párrafo anterior, se hiciese un nuevo balance de

prioridades y se optase por proporcionar más recursos a los traductores, quienes además

no tendrían por qué comprometer la privacidad del código (a menudo estos

profesionales firman un contrato de confidencialidad).

145

Otro de los aspectos a resolver es el problema de espacio, algo para cuya solución

pueden contribuir tanto desarrolladores como traductores o localizadores, pues un

acercamiento jamás puede producirse si todas las partes no deciden involucrarse en el

mismo; el deseo de aproximación de posturas debe ser mutuo.

Mientras que es importante que los desarrolladores tengan en cuenta que la extensión de

los textos varía en función del idioma al que se traducen los mismos y por tanto es

aconsejable que no utilicen dimensiones fijas para los menús, botones, etc., también es

importante que los traductores entiendan que la solución a esto no siempre está en

manos de los desarrolladores y que por tanto deberán tratar de reformular algunas frases

para que estas sean algo menos extensas.

No obstante, esta tarea resulta mínima en comparación con todo aquello que se puede

hacer al respecto: al igual que los desarrolladores deben poner de su parte, también es

importante que los localizadores no limiten su actividad al mero aspecto lingüístico y se

beneficien de los nuevos recursos presentes en el sector.

Con estos nuevos recursos nos referimos concretamente a las llamadas herramientas in-

context o de localización visual. Estas resultan tremendamente útiles en la corrección de

problemas relacionados con el espaciado.

A este respecto, Guttinger presenta información muy relevante que queda recogida en el

libro de Singh (2012, 145-146):

“[…] Translators used to be expected only to provide translations. Today they are also expected to

perform basic localization tasks, such as resizing, spell-checking, alignment, leveraging, and the

like. To be able to perform these tasks, they need visual localization tools. […] The term ‘visual localization’ refers to the process of translating and localizing the graphical user interfaces (GUIs),

including things such as dialog boxes, menus, and other visual elements in software products and

websites, using commercially available software translation/localization tools. Examples of such

visual localization tools are SDL Passolo and Alchemy Catalyst. These are some of the common

tools, and many more are available. Unlike standard translation memory tools – in which

translators localize text strings ‘blindly’ (i.e., without knowing what they will look like at run-

time) – visual localization tools offer WYSIWYG (what you see is what you get) environments

that make localizing applications and web pages much simpler. They tend to be easy to use, with a

customizable interface, and they support a variety of file formats.”

Estas herramientas permiten al localizador o traductor ver el resultado final, hecho por

el cual estos profesionales pueden evitar que se den problemas de espaciado que acaban

resultando en truncamientos y oraciones cortadas. Además, como consecuencia de lo

mismo, las traducciones son más exactas y precisas y la fase de QA resulta menos

costosa.

En línea con el uso de estas herramientas, cabe decir que el aprovechamiento de nuevos

recursos puede realizarse por ambas partes, ya que tanto desarrolladores como

localizadores pueden valerse de recursos como el Django, un framework que, según

Roturier (2015), ofrece numerosos recursos para la internacionalización y la

localización y cuenta con funcionalidades pensadas especialmente para facilitar la labor

de los traductores.

146

En definitiva, si algo ha quedado claro a lo largo de este trabajo, es que este

acercamiento debe verse como algo fundamental para el avance y mejora de las

aplicaciones y páginas web y necesita de la voluntad de todas las partes implicadas en la

creación de estos productos tan presentes en el día a día de las millones de personas que

constituyen un mundo tremendamente interconectado.

13. Bibliografía:

AA.VV. (2018), Avoid hardcoding, Drupal, https://www.drupal.org/docs/7/site-

building-best-practices/avoid-hardcoding

AA.VV. (2015), Comentarios en el código de Visual Basic, Microsoft,

https://docs.microsoft.com/es-es/dotnet/visual-basic/programming-guide/program-

structure/comments-in-code

AA.VV. (2018), Cómo funciona CSS, Mozilla,

https://developer.mozilla.org/es/docs/Learn/CSS/Introduction_to_CSS/Como_funciona

_CSS

AA.VV. (s.d), CSS Introduction, w3schools.com,

https://www.w3schools.com/css/css_intro.asp

AA.VV. (s.d), GNOME Developer: Escribiendo estilos, The GNOME Project,

https://developer.gnome.org/hig/stable/writing-style.html.es

AA.VV. (s.d), GNOME Developer: Iconos y diseño, The GNOME Project,

https://developer.gnome.org/hig/stable/icons-and-artwork.html.es

AA.VV. (s.d), GNOME Translation project: L10N Guidelines for Developers, The

GNOME Project, https://wiki.gnome.org/TranslationProject/DevGuidelines

AA.VV. (s.d), GNOME Translation project: Use comments, The GNOME Project,

https://wiki.gnome.org/TranslationProject/DevGuidelines/Use%20comments

AA.VV. (s.d), Globalización paso a pas, Microsoft Developer Network,

https://msdn.microsoft.com/es-es/goglobal/bb688127.aspx

AA.VV. (s.d), GNU Coding Standards: Naming Variables, Functions, and Files, GNU,

https://www.gnu.org/prep/standards/html_node/Names.html

AA.VV. (2018), Gnucash, https://wiki.gnucash.org/wiki/GnuCash

AA.VV. (2018), Gnucash: Coding Standard,

https://wiki.gnucash.org/wiki/CodingStandard

AA.VV. (2018), Gnucash: Development, https://wiki.gnucash.org/wiki/Development

AA.VV. (s.d), Gnucash for Android, Coding User, http://codinguser.github.io/gnucash-

android/

https://www.drupal.org/docs/7/site-building-best-practices/avoid-hardcoding

https://www.drupal.org/docs/7/site-building-best-practices/avoid-hardcoding

https://docs.microsoft.com/es-es/dotnet/visual-basic/programming-guide/program-structure/comments-in-code

https://docs.microsoft.com/es-es/dotnet/visual-basic/programming-guide/program-structure/comments-in-code

https://developer.mozilla.org/es/docs/Learn/CSS/Introduction_to_CSS/Como_funciona_CSS

https://developer.mozilla.org/es/docs/Learn/CSS/Introduction_to_CSS/Como_funciona_CSS

https://www.w3schools.com/css/css_intro.asp

https://developer.gnome.org/hig/stable/writing-style.html.es

https://developer.gnome.org/hig/stable/icons-and-artwork.html.es

https://wiki.gnome.org/TranslationProject/DevGuidelines

https://wiki.gnome.org/TranslationProject/DevGuidelines/Use%20comments

https://msdn.microsoft.com/es-es/goglobal/bb688127.aspx

https://www.gnu.org/prep/standards/html_node/Names.html

https://wiki.gnucash.org/wiki/GnuCash

https://wiki.gnucash.org/wiki/CodingStandard

https://wiki.gnucash.org/wiki/Development



147

AA.VV. (2018), Gnucash: GUI Guideline,

https://wiki.gnucash.org/wiki/GUI_Guidelines

AA.VV. (s.d), Gnucash Help Manual: Changing the Language, Gnucash.org,

https://www.gnucash.org/docs/v3/C/gnucash-help/chang-lang.html

AA.VV. (2017), Gnucash Project and Design Documentation: Architectural Goals,

https://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Architectural_Goals

AA.VV. (2018), Gnucash: Translation, https://wiki.gnucash.org/wiki/Translation

AA.VV. (2018), Introducción a Android Studio: Combinaciones de teclas, Android

Developers, https://developer.android.com/studio/intro/keyboard-shortcuts?hl=es

AA.VV. (2017), Los 10 lenguajes de programación más demandados en 2017, blog

aprendum, http://blog.aprendum.com/lenguajes-de-programacion-mas-demandados-

2017/

AA.VV. (s.d), Manual de php: Variables, conceptos básicos, php.net,

http://php.net/manual/es/language.variables.basics.php

AA.VV. (2014), Notepad++ Guides/User Guides, NpWiki++, http://docs.notepad-plus-

plus.org/index.php/NP%2B%2B_Guides

AA.VV. (s.d), ¿Qué es un lenguaje interpretado?, lenguajesdeprogramacion.net,

https://lenguajesdeprogramacion.net/diccionario/que-es-un-lenguaje-interpretado/

AA.VV. (s.d), Repositorio Notepad++, Github https://github.com/notepad-plus-

plus/notepad-plus-plus

AA.VV. (s.d), Repositorio Gnucash, Github, https://github.com/Gnucash/gnucash

AA.VV. (s.d), Repositiorio Gnucash Android, Github,

https://github.com/codinguser/gnucash-android

AA.VV. (2018), Scintilla Documentation, Scintilla,

https://www.scintilla.org/ScintillaDoc.html

AA.VV. (s.d), Tipos de variables PHP, Tutoriales Programación Ya,

http://www.tutorialesprogramacionya.com/phpya/temarios/descripcion.php?punto=5&c

od=26&inicio=0

AA.VV. (s.d), Translation software and other projects, Translation Project,


AA.VV. (s.d), Tutorial del Servidor Apache HTTP: Ficheros .htaccess, APACHE,

https://httpd.apache.org/docs/current/es/howto/htaccess.html

AA.VV. (s.d), What is .htaccess?, Htaccess, http://www.htaccess-guide.com

https://wiki.gnucash.org/wiki/GUI_Guidelines

https://www.gnucash.org/docs/v3/C/gnucash-help/chang-lang.html

https://wiki.gnucash.org/wiki/Project_and_Design_Documentation#Architectural_Goals

https://wiki.gnucash.org/wiki/Translation

https://developer.android.com/studio/intro/keyboard-shortcuts?hl=es

http://blog.aprendum.com/lenguajes-de-programacion-mas-demandados-2017/

http://blog.aprendum.com/lenguajes-de-programacion-mas-demandados-2017/

http://php.net/manual/es/language.variables.basics.php

http://docs.notepad-plus-plus.org/index.php/NP%2B%2B_Guides

http://docs.notepad-plus-plus.org/index.php/NP%2B%2B_Guides

https://lenguajesdeprogramacion.net/diccionario/que-es-un-lenguaje-interpretado/

https://github.com/notepad-plus-plus/notepad-plus-plus

https://github.com/notepad-plus-plus/notepad-plus-plus

https://github.com/Gnucash/gnucash

https://github.com/codinguser/gnucash-android

https://www.scintilla.org/ScintillaDoc.html

http://www.tutorialesprogramacionya.com/phpya/temarios/descripcion.php?punto=5&cod=26&inicio=0

http://www.tutorialesprogramacionya.com/phpya/temarios/descripcion.php?punto=5&cod=26&inicio=0


https://httpd.apache.org/docs/current/es/howto/htaccess.html

http://www.htaccess-guide.com/

148

AA.VV. (s.d), What is App Store Optimization?, The Tool, https://thetool.io/aso-app- store-

optimization

AA.VV. (s.d), What is open source?, opensource.com,

https://opensource.com/resources/what-open-source

AA.VV. (2017), Writing Direction and Bidirectional Text FAQ, unicode.org,

http://unicode.org/faq/bidi.html

ÁLVAREZ, Miguel Ángel (2018), Qué es Sass, cómo usar Sass, DesarrolloWeb.com,

https://desarrolloweb.com/articulos/que-es-sass-usar-sass.html

ÁLVAREZ, Ruben et alii. (2016), Manual de HTML, Desarrolloweb.com. BUTTFIELD-

ADDISON, Paris et alii. (2016), Learning Swift, O'Reilly Media, Inc.

CEVOLI, Marco (2016), Herramientas gratuitas para traductores II: Notepad++, Qabiria,

https://qabiria.com/es/blog/item/509-herramientas-gratuitas-para-traductores- notepad

CUERVO, Víctor (2006), Comentarios en Java, Línea de código,

http://lineadecodigo.com/java/comentarios-en-java/

CUERVO, Víctor (s.d), Variables en Java, Manual Web,

http://www.manualweb.net/java/variables-java/

DE LA COVA, Elena (2016), «Translation Challenges in the Localization of Web

Applications», en Sendebar 27, Revista de Traducción e Interpretación de la

Universidad de Granada, págs. 235-266.

http://revistaseug.ugr.es/index.php/sendebar/article/view/4942/5061

EGUILUZ, Javier (s.d), Introducción a CSS: Colores, Libros Web,

http://librosweb.es/libro/css/capitulo_3/colores.html

EGUILUZ, Javier (s.d), Introducción a JavaScript: Tipos de variables, Libros Web,

http://librosweb.es/libro/javascript/capitulo_3/tipos_de_variables.html

EGUILUZ, Javier (s.d), Introducción a JavaScript: Variables, Libros Web,

http://librosweb.es/libro/javascript/capitulo_3/variables.html

ESSELINK, Bert (2000), A Practical Guide to Localization, Amsterdam, John

Benjamins Publishing.

ESSELINK, Bert (2003), «The Evolution of Localization», en Multilingual Computing and

Technology, págs. 22-29,

http://www.intercultural.urv.cat/media/upload/domain_317/arxius/Technology/Esselink

_Evolution.pdf

https://thetool.io/aso-app-store-optimization



https://opensource.com/resources/what-open-source

http://unicode.org/faq/bidi.html

https://desarrolloweb.com/articulos/que-es-sass-usar-sass.html

https://qabiria.com/es/blog/item/509-herramientas-gratuitas-para-traductores-notepad

https://qabiria.com/es/blog/item/509-herramientas-gratuitas-para-traductores-notepad

http://lineadecodigo.com/java/comentarios-en-java/

http://www.manualweb.net/java/variables-java/

http://revistaseug.ugr.es/index.php/sendebar/article/view/4942/5061

http://librosweb.es/libro/css/capitulo_3/colores.html

http://librosweb.es/libro/javascript/capitulo_3/tipos_de_variables.html

http://librosweb.es/libro/javascript/capitulo_3/variables.html

http://www.intercultural.urv.cat/media/upload/domain_317/arxius/Technology/Esselink_Evolution.pdf

http://www.intercultural.urv.cat/media/upload/domain_317/arxius/Technology/Esselink_Evolution.pdf

149

FET, Ngewi (2012), Gnucash for Android beta 2 – Lost in translation, Coding User,

http://www.codinguser.com/2012/09/gnucash-for-android-beta-2-lost-in-translation/

GONZALEZ COLLADO, Sergio (2018), Introducción a HTML, Mozilla,

https://developer.mozilla.org/es/docs/Learn/HTML/Introduccion_a_HTML

HELLER, Eva (2004), Psicología del color: Cómo actúan los colores sobre los

sentimientos y la razón, Barcelona, Gustavo Gili, SL. págs. 51-73.

HO, Don (2016), Translate Notepad++ binary, https://notepad-plus-

plus.org/contribute/binary-translation-howto.html

HURTADO ALBIR, Amparo (2011), Traducción y traductología: introducción a la

traductología, Madrid, Cátedra, págs. 31-42 y 87-91.

ISHIDA , Richard (2017), Time & date: Essential concepts, W3C,

https://www.w3.org/International/articles/definitions-time/index

JIMÉNEZ-CRESPO, Miguel Ángel (2017), Crowdsourcing and Online Collaborative

Translations, Amsterdam / Filadelfia, John Benjamins Publishing, págs. 11-23.

MUÑOZ, Pablo (2017), Localización de aplicaciones móviles, Traduversia,

https://traduversia.com/curso/localizacion-de-aplicaciones-moviles/

PYM, Anthony (2004), The Moving Text Localization, Translation, and Distribution, Ámsterdam/Filadelfia, John Benjamins.

PYM, Anthony (2003), «What Localization Models Can Learn From Translation Theory»,

en LISA Newsletter. Globalization Insider, http://usuaris.tinet.cat/apym/on-

line/translation/localization_translation_theory.pdf

REDONDO, Félix (2016), El Índice TIOBE: ¿cómo medir qué lenguajes de programación

son los más usados?, Paradigma Digital, https://www.paradigmadigital.com/dev/el-

indice-tiobe-como-medir-que-lenguajes-de- programacion-son-los-mas-usados/

REINO ROMERO, Alfredo (s.d), Manual de XML, Desarrolloweb.com.

RIERA, Alejandro (2012), Los comentarios, GitHubGist,

https://gist.github.com/ariera/4388094

ROTURIER, Johann (2015), Localizing Apps: A practical guide for translators and

translation students, Nueva York, Routledge.

ROUSE, Margaret (2008), What is key-value pair?, TechTarget,

https://searchenterprisedesktop.techtarget.com/definition/key-value-pair

SANDRINI, Peter (2008), «Localization and Translation», en MuTra Journal 2, págs 167-

191, http://www.petersandrini.net/publik/localiz.pdf

http://www.codinguser.com/2012/09/gnucash-for-android-beta-2-lost-in-translation/

https://developer.mozilla.org/es/docs/Learn/HTML/Introduccion_a_HTML

https://notepad-plus-plus.org/contribute/binary-translation-howto.html

https://notepad-plus-plus.org/contribute/binary-translation-howto.html

https://www.w3.org/International/articles/definitions-time/index



http://usuaris.tinet.cat/apym/on-line/translation/localization_translation_theory.pdf

http://usuaris.tinet.cat/apym/on-line/translation/localization_translation_theory.pdf

https://www.paradigmadigital.com/dev/el-indice-tiobe-como-medir-que-lenguajes-de-programacion-son-los-mas-usados/



https://gist.github.com/ariera/4388094

https://searchenterprisedesktop.techtarget.com/definition/key-value-pair

http://www.petersandrini.net/publik/localiz.pdf

150

SINGH, Nitish (2012), Localization Strategies for Global E-Business, Reino Uindo,

Cambridge University Press. págs 1-208.

VILLACAMPA, Òscar (2015), Qué es SASS y por qué los CSS pueden volver a divertirnos,

Ondho, https://www.ondho.com/que-es-sass-y-por-que-los-css-pueden- volver-a-

divertirnos/

VILLENA, José Javier (2017), Fundamentos de la programación: Áreas de

programación, Udemy, https://www.udemy.com/fundamentos-de-la-

programacion/learn/v4/t/lecture/6943414?start=360

VILLENA, José Javier (2017), Fundamentos de la programación: Lenguajes compilados VS

interpretados, Udemy, https://www.udemy.com/fundamentos-de-la-


VILLENA, José Javier (2017), Fundamentos de la programación: Qué es un lenguaje de

programación, Udemy, https://www.udemy.com/fundamentos-de-la-


VILLENA, José Javier (2017), Fundamentos de la programación: Qué es un programa,

Udemy, https://www.udemy.com/fundamentos-de-la-


VILLENA, José Javier (2017), Fundamentos de la programación: Variables, tipos de datos y

constantes, Udemy, https://www.udemy.com/fundamentos-de-la-


YUNKER, John (2003), Beyond Borders: Web Globalization Strategies, Estados

Unidos, New Riders.

https://www.ondho.com/que-es-sass-y-por-que-los-css-pueden-volver-a-divertirnos/



https://www.udemy.com/fundamentos-de-la-programacion/learn/v4/t/lecture/6943414?start=360










Utopía y realidad de los proyectos de localización. Un … · 2019-10-23 · 3 Resumen: Este...

Documents

Transcript of Utopía y realidad de los proyectos de localización. Un … · 2019-10-23 · 3 Resumen: Este...