Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Bienvenidas y bienvenidos a la wiki del equipo de traducción de elementary OS al español. Esta guía habla de detalles específicos de elementary para la localización al español. Este documento pretende unificar las traducciones de todas las variantes del español y nos ayuda a tener una traducción coherente y unificada para elementary en nuestro idioma.
Esta guía no es una biblia inmutable e indiscutible.
Es un conjunto de referencias y acuerdos entre las personas que han traducido elementary al español que nos resultan convenientes a la hora de traducir el sistema operativo y sus aplicaciones. Y debido a que el español está en continua evolución, las recomendaciones que consignemos aquí hoy pueden cambiar.
Si tiene una petición, queja, reclamo o sugerencia constructiva, es más que bienvenida. Recomendamos iniciar la discusión en:
A continuación discutiremos sobre aspectos específicos de la traducción de elementary OS al idioma español.
La distribución de elementary OS pretende ser una distribución concisa y simple, pero potente.
Esto hace que las interfaces hacia el usuario deban ser simples, concisas y fáciles de entender para usuarios que no son ávidos consumidores de tecnología, o expertos en manejar sistemas. Pero, a su vez, un usuario con conocimientos puede darle un gran uso a su equipo en tareas del día a día y mucho más.
Esto, como filosofía, debe representarse en toda traducción que se haga. En la práctica, lo que se evita es ser excesivamente técnico o abstracto y tratar siempre de virar hacia lo sencillo, conciso y claro.
En este instante no se tiene como objetivo tener localizaciones regionales. Estamos asumiendo la traducción al español como un español neutro, posible de entender para toda la región hispanoamericana.
Esto significa que en Weblate, a pesar de que pueden existir otras regiones, en particular «Español (México)», o es_MX, no vamos a realizar traducciones en esa área, ya que no se piensan utilizar en elementary a futuro. Solamente tendremos actualizada la región principal, que en Weblate es Español a secas.
El nombre elementary consiste de tres elementos:
elementary: Usualmente, se refiere al equipo de desarrollo.
elementary OS: El sistema operativo como tal.
elementary, Inc.: La empresa y razón social detrás de elementary y elementary OS.
Este conjunto de nombres tienen las siguientes reglas:
Nunca deben ser traducidos. Es decir, nunca debe referirse como «elemental» o traducir el acrónimo OS a SO
Nunca debe escribirse en mayúsculas, con la excepción del acrónimo si aparece. Al inicio de una frase debe mantenerse la minúscula. Si es posible, es recomendable modificar el texto para que elementary o elementary OS no sea la primera palabra de la frase.
Se permite reemplazar OS (en caso de que aparezca) por «sistema operativo» si esto corrige la necesidad de tener elementary como la primera palabra de una frase.
Si no hay manera de tener una traducción adecuada sin tener «elementary» al inicio de la frase, se permite como último recurso dejarlo tal como está.
Si elementary aparece sin el acrónimo OS, no es necesario añadírselo, ya que usualmente se refiere al equipo de trabajo. Si se mencionan las palabras operative system se traducirá normalmente a «sistema operativo».
En la traducción de elementary, Inc. no se debe traducir la parte Inc., ya que no existe un equivalente hispanoamericano universal a la razón social de la empresa.
Ejemplo uno
elementary OS automatically checks your Internet connection when you connect to a new Wi-Fi network.
Se traduce a:
El sistema operativo elementary comprueba automáticamente su conexión a Internet cuando se conecta con una red wifi nueva.
Ejemplo dos
The elementary brand belongs to elementary, Inc., the company that guides and supports development of elementary products.
Se traduce a:
La marca elementary pertenece a elementary, Inc., la compañía que guía y apoya el desarrollo de los productos elementary.
Ejemplo tres
Get help installing elementary OS with our step-by-step guide.
Se traduce a:
Aprenda a instalar elementary OS con nuestra guía paso a paso.
En elementary estamos traduciendo algunos nombres de aplicaciones, pero otras no. Existen diferentes razones para traducir o no traducir ciertos nombres.
En todo caso, el nombre de la aplicación debe tener siempre mayúsculas al inicio de cada palabra, excepto por artículos y conjunciones (por ej. «Centro de Aplicaciones», nótese la C y la A mayúsculas).
Esto rompe con la convención normal del español de no hacer capitalizaciones en cada palabra, pero para nombres propios se hace una excepción.
También, al ser nombres propios, no es necesario distinguirlos de nombre extranjeros con el tipo letra itálica.
El nombre es un nombre de una aplicación de uso común, fácil de traducir (por ejemplo, Calculator se traduce a «Calculadora»)
El nombre tiene un equivalente claro en español que no distraería de su uso diario (por ejemplo, AppCenter se traduce a «Centro de Aplicaciones»)
No existe una traducción clara en español que podría producir más confusión. Por ejemplo, Sideload no tiene una palabra clara, existe «transferencia local», pero en el contexto de elementary, no se está usando exactamente como una transferencia local, sino más bien como una aplicación externa. De hecho, cuando se refiere a sideload en las traducciones, es más apropiado hablar de una «instalación externa».
Cuando el nombre como tal no aporta nada a la interfaz del usuario o cuando es un nombre código que se usa más por los programadores y sería confuso traducirlo (por ej. Granite, siendo un conjunto de bibliotecas sobre GTK4 para programadores, causaría más confusión traducirlo porque nunca se refiere así internamente y no representa nada para un usuario común. Por lo tanto, lo dejamos sin cambios).
Los plugs son los complementos externos que se utilizan en la aplicación de Switchboard o Configuración del Sistema. En varios puntos de la traducción es común referirse a estos plugs.
Las reglas de nombre para estos plugs son similares a las aplicaciones, con la excepción de que solamente se conserva en mayúscula la primera palabra después del prefijo «configuración», pero las demás palabras permanecen en minúscula.
Las notas de las versiones usualmente se pueden encontrar en las secciones (extra) de Weblate.
Estas secciones se refieren a notas de nuevas versiones respecto a correcciones, mejoras y nuevas funcionalidades.
Se recomienda, al referirse a estas secciones, al ser notas de versiones, como elementos que han cambiado, corregido o agregado, por lo que se recomienda utilizar verbos en pasado con pronombres reflexivos, particularmente el uso de se si resulta posible.
No es una obligación siempre usar esta forma gramatical, pero es altamente recomendado siempre que se pueda hacer.
El siguiente texto, referido a una nueva característica en la aplicación Code:
New custom dark and light elementary styles for the source view
Se traducirá a:
Se agregó un nuevo estilo claro y oscuro de elementary para la vista de código
Es importante mencionar que una gran parte de esta información se ha tomado de los equipos de traducción al español de Ubuntu y de Fedora, así como el diccionario de términos técnicos e informáticos de Microsoft y el Diccionario panhispánico de dudas de la RAE.
Se recomienda leer y revisar frecuentemente estas guías para tener claro todos los aspectos de traducción al español para elementary OS.
Guía de estilo de Ubuntu al español: Ubuntu Spanish Translators
Guía de estilo de Fedora al español: Fedora L10N Spanish Team
Diccionario de términos técnicos e informáticos de Microsoft: Microsoft Terminology y Microsoft Terminology Search
Manual de la RAE con diversos temas Diccionario panhispánico de dudas
Si hay alguna contradicción entre estas guías y lo explicado aquí, este documento y el glosario de términos tienen precedencia sobre las guías base.
Guidelines to make code reviews fruitful for developers and reviewers alike
Code reviews play a crucial role in the development process. Having other people verify your code not only improves overall code quality, it serves an even bigger purpose: providing an opportunity to learn from each other. This guide aims to lower the barrier to reviewing code by providing a common ground of best practices and philosophies which have proved to be useful over the years.
The roles of developer and reviewer are not mutually exclusive—you can be both. And we highly encourage you to perform both roles, because this leads to more diverse reviews which help us to improve the overall user experience of elementary OS.
You don't need to fully understand the codebase to test its functionality. Often the feedback provided by a partial review helps to keep the momentum and multiple partial reviews eventually lead to a full review.
If there's code you don't understand, ask about what it does. The chances are good it either needs a comment, could be refactored, or you get to learn something new!
Because of Murphy's law ("Anything that can go wrong will go wrong") we want to make extra sure to keep an eye on potential pitfalls during code review. This is especially true for code that is responsible for carrying out a user's intent. Code which fails to execute a user initiated action and is unable to inform the user about the error leads to a bad experience.
If you come across something you like about a proposed change, don't hesitate to let the developer know. Its just more fun to work with people who recognize the effort made.
Aquí exponemos algunas prácticas no recomendadas que pueden causar problemas al hacer traducciones correctas para elementary.
El fundamento de esta recomendación es que la traducción de elementary se pretende ser para un español internacional. Significa que se deben evitar palabras, jergas y expresiones locales que no sean universales en la región hispanoamericana.
Esto es más difícil de lo que parece, ya que cada región tiene expresiones que, aunque pueden sonar bien en una zona, sonarán mal o fuera de tono en otra. La recomendación aquí es utilizar fuentes como el para obtener información sobre una palabra o expresión y observar si es algo específico de una región o no.
Por esta misma razón, se debe ser lo más neutral posible al expresarse al usuario. Se debe evitar tanto el voseo y el tuteo, como formas coloquiales de referencia al usuario, por la misma razón expuesta anteriormente.
Este texto:
Type to test your settings
You’re connected!
Se traduciría a:
Escriba para probar su configuración
¡Está conectado!
No se permiten formas como:
Escribe para probar tu configuración
¡Estás conectado!
Escribí y probá tu configuración
¡Vos estáis conectado!
El presente progresivo no siempre se debe traducir literalmente al español. Muchas veces en inglés, aunque se use esta conjugación, se está indicando algo en tiempo presente, futuro, o el verbo en infinitivo.
En resumen, la terminación -ing no necesariamente representa un verbo terminado en «-ando» o «-iendo».
El siguiente texto:
After restarting you can set up a new user, or you can shut down now and set up a new user later.
Se traduciría a:
Después de reiniciar, puede configurar una cuenta de usuario nueva, o puede apagar ahora y configurarla más tarde.
Nótese que utilizar el verbo restarting como «reiniciando» no tendría sentido en esta frase, es necesario usar el verbo en infinitivo para que funcione.
En español, las comillas inglesas (“, ” o ") o comillas sencillas (` o ') no se utilizan a menos que sea absolutamente necesario. De manera predeterminada, siempre usaremos comillas españolas o angulares (« y ») para textos comunes para el usuario.
Excepciones para utilizar las comillas inglesas o de hacker son:
Secciones de código de ejemplo de lenguajes de programación como Vala, donde la sintaxis exige el uso de comillas inglesas o comillas simples.
Etiquetas de navegador internas del lenguaje HTML, Markdown que exigen el uso de comillas simples y no se pueden cambiar. De lo contrario, el formato de estos lenguajes se rompería.
En Linux, estos caracteres se pueden escribir con la combinación de teclas Alt Gr + Z y Alt Gr + X, respectivamente, con las distribuciones de teclado hispanoamericanas con teclas muertas. En Windows esto se realiza con la combinación Alt + 174 y Alt + 175, respectivamente.
El sitio web de Weblate también ofrece botones que pueden ser presionados con el ratón para colocar estos caracteres.
El texto:
The program "io.elementary.calendar" may not be installed
Se traduce a:
Es posible que el programa «io.elementary.calendar» no esté instalado
Take this time to read the <a href="/docs/learning-the-basics">getting started</a> guide to learn about your new operating system.
Se traduce a:
Dedique un momento a leer la <a href="/docs/learning-the-basics">guía de primeros pasos</a> para aprender a utilizar su nuevo sistema operativo.
Nótese que no se traducen las comillas de la etiqueta HTML, ya que es una exigencia para que funcione correctamente y la dejamos como está.
Las etiquetas HTML y otros aspectos de código HTML (o de lenguajes de programación como Vala) tienen una exigencia de sintaxis que no debe ser alterada, ya que rompería el formato HTML y puede causar problemas. Estas partes del texto nunca deben ser traducidas.
You can also secondary-click a window's header bar and choose <strong>Resize</strong> or press <kbd>Alt</kbd><kbd>F8</kbd> to enter resize mode.
Se traduce a:
También puede hacer clic con el botón secundario en la barra de encabezado de una ventana y elegir <strong>Redimensionar</strong> o presionar <kbd>Alt</kbd><kbd>F8</kbd> para ingresar al modo redimensionar.
Nótese que las etiquetas <strong> y <kbd> no se traducen. Se conserva su estructura para que el formato HTML dibuje correctamente el resultado final.
Ejemplos de palabras pueden ser actualmente, automáticamente, momentáneamente, especialmente, nuevamente, accidentalmente, permanentemente, etc.
Estas palabras no tienen nada malo per se. Lo que ocurre es que es muy común abusar de ellas, resultando en una traducción llena de este tipo de palabras.
El uso de estas palabras es más tolerable en secciones de documentación o notas de versión. Pero es preferible intentar encontrar alternativas cuando se trata de elementos de interfaz de usuario.
Sin embargo, esta no es una regla inmutable. Es posible que en algunos casos no se pueda evitar usar el adverbio, e incluso puede ser la mejor palabra dado el contexto. Pero se recomienda al menos tratar de encontrar alternativas si se siente que la traducción no se beneficia de la palabra actual.
Por ejemplo este texto del complemento de sonido de la Configuración del Sistema:
No applications currently emitting sounds. Applications emitting sounds will automatically appear here.
Si lo traducimos con las palabras terminadas en «...mente» obtendríamos algo como esto:
No hay aplicaciones emitiendo sonidos actualmente. Las aplicaciones que emitan sonidos aparecerán aquí automáticamente.
Nótese que hay mucha redundancia y aliteración con el uso excesivo del adverbio. Una traducción un poco mejor sería algo como esto:
No hay aplicaciones emitiendo sonidos en este momento. Las aplicaciones que emitan sonidos aparecerán aquí de forma automática.
El español en herramientas técnicas, como aplicaciones y sistemas operativos, no se usan tantas palabras de cortesía, a diferencia del inglés. Muchas veces se considera superfluo e innecesario agregar estos detalles en español, resultando molesto (precisamente, la intención contraria de lo que desea).
En particular, el uso de please en inglés es muy común, pero que en español se suele omitir. Por lo general, el imperativo en español suena mejor a la hora de pedir aclaraciones o solicitar acciones.
Una excepción a esta regla es cuando se hacen preguntas al usuario para realizar o confirmar una acción. En esta situación es recomendable utilizar la cortesía, en particular el uso del verbo «desear» y preguntar confirmaciones con «está seguro que...». Estamos prefiriendo el verbo «desear» sobre otros como «querer» y «está seguro que...» sobre «confirma que...».
Otra excepción también surge cuando es claro que es un error o dificultad que está fuera del control del usuario o del sistema.
Finalmente, es recomendado también enviar la cortesía al referirse a elementos del usuario y evitar la segunda persona. Por ejemplo, your message es preferible traducirlo a «el mensaje» en vez de «su mensaje».
Ejemplo uno
Este texto:
Please restart your system to finalize updates
Se traduce así:
Reinicie el sistema para terminar de instalar las actualizaciones
En este caso, evitamos traducir please para evitar el exceso de cortesía y simplemente se usa la forma imperativa en la oración.
Ejemplo dos
Este texto a continuación:
An error occurred while processing the card. Please try again later. We apologize for any inconvenience caused.
Se traduce de esta manera:
Se ha producido un error al procesar la tarjeta. Inténtelo de nuevo más tarde. Sentimos cualquier inconveniente causado.
Nótese que la última parte sí se traduce, porque en este contexto (un error de procesamiento de pago de tarjeta) puede provocar un «pago fantasma» creando un inconveniente serio al usuario, pero fuera del control del sistema y del usuario. Por lo tanto en este caso, pedimos disculpas.
Ejemplo tres
Y finalmente este texto:
Are you sure you want to Log Out?
Se traduce así:
¿Está seguro que desea cerrar la sesión?
Aquí se usa la forma cortés de «desear» y solicitamos la confirmación con «está seguro», puesto que es una pregunta para una posible acción «irreversible» por decirlo de una forma.
Los pronombres reflexivos (me, te, se, nos) y los verbos modales (deber, poder, tener, haber que) son mucho más usados de lo que se cree en español. Por lo general, se utilizan para:
Referirse a eventos pasados o presentes cuando se producen errores o algún proceso falla.
Lo común aquí es el uso de «se pudo», «no se pudo», «se ha producido» etc.
Traducir palabras en inglés como may a su respectivo verbo modal, dependiendo del contexto.
Al hablar de actualizaciones y notas de versión, el pronombre reflexivo «se» es común de usar para hablar de cambios y demás.
Una excepción de los verbos modales es con «haber que», «hubo», etc. Usualmente, se prefiere el uso del pronombre reflexivo «se» para este tipo de expresiones.
Ejemplo uno
Este texto:
This may have been caused by sideloaded or manually compiled software, a third-party software source, or a package manager error. Manually refreshing updates may resolve the issue.
Se traduce a:
Esto puede deberse a instalaciones externas o aplicaciones compiladas manualmente, una fuente de aplicaciones de terceros, o un error en el gestor de paquetes. Refrescar las actualizaciones podría solucionar el problema.
Nótese el uso diferente de los verbos modales en ambas acepciones de may. Existe una intención ligeramente diferente en cada oración.
Ejemplo dos
Este texto, en relación a una nota de actualización de versión
Improve brightness in the dark style
Se traduce a:
Se mejoró el brillo en el estilo oscuro
El texto:
There was an unexpected error while sending your message.
Se podría traducir a:
Hubo un error inesperado mientras se enviaba su mensaje.
Pero la semantica resulta un poco extraña. El pronombre reflexivos nos ayuda a mencionar que este fue un evento que ya ocurrió, fue registrado
en cuyo caso preferimos traducilor a:
Se ha producido un error inesperado al enviar el mensaje.
Los siguientes textos:
Could not save configuration
Firewall rules can't be changed without the required system permission.
Se traducen a:
No se pudo guardar la configuración
Las reglas del cortafuegos no se pueden cambiar sin los permisos necesarios.
A la hora de traducir, es importante poder distinguir entre los nombres propios de las aplicaciones versus el uso común de las palabras que representan.
En particular, una aplicación, servicio o plug, al ser un nombre propio, debe ir siempre en su formato correcto, especificado en el glosario de términos y, si es posible, evitar referirse a la aplicación antecedida de un artículo (por ejemplo, es «Correo», no «el Correo»).
Las traducciones literales nunca son recomendadas. Es muy común querer traducir palabra por palabra la forma verbal del inglés para simular el flujo del idioma original. El español tiene una estructura diferente y utiliza modismos y estructuras verbales de manera distinta que el inglés.
La sugerencia de esta guía es siempre leer la frase completa primero y entender el contexto detrás de ella para luego traducir. Trate de ver el todo de la frase y no sus palabras individuales para enviar el mismo mensaje, así no resulte necesariamente en una traducción literal.
Es recomendable evitar transliterar o traducir palabra a palabra, es decir, leer la primera palabra, traducirla, ir a la siguiente, traducirla, etcétera. Esto suele crear frases extrañas con una composición que no se siente natural al idioma español.
Consideremos esta frase:
This site uses cookies for incremental improvements. You may find the services function without them but at a reduced usability.
La traducción literal tanto en palabras como gramatical resultaria en:
Este sitio usa cookies para mejoras incrementales. Usted puede encontrar que los servicios funcionen sin ellas pero a una reducida usabilidad.
Pero esto no se siente natural, tanto en vocablos como en gramática. Una traducción centrada más en la comprensión general de la frase sería algo como lo siguiente:
Este sitio utiliza cookies para realizar mejoras continuas. Puede utilizar los servicios sin ellas pero con una usabilidad reducida.
No se recomienda el uso de estos servicios y, de hecho, se prefiere evitarlos completamente.
Existen múltiples razones para ello:
Estos servicios gratuitos muchas veces son exclusivamente para uso personal y los términos legales de estos servicios suelen ser complicados de usar para una organización como elementary, Inc., exigiendo el pago de licencias comerciales para un proyecto como elementary OS.
Muchas veces estos traductores hacen traducciones literales. Esto significa que deciden traducir términos de manera literal, sin conocer el contexto del texto o su nivel técnico. Por ejemplo, muchas veces se traducen palabras de nombres en inglés sin posibles traducciones propias al término técnico como cookies (en el contexto web, que traducen a «galletas») o plugs (en el contexto de los complementos de elementary, que traducen a «enchufe»), que no tendrían cabida o sentido en la traducción final.
A veces los traductores ofrecen traducciones de palabras que no tienen un perfecto significado a lo que se refiere. Por ejemplo, sideload puede llegar a traducirse como «transferencia local» o «carga lateral» que, aunque técnicamente correctos, en el contexto de elementary no serían los términos precisos y puede llegar a confundir (en elementary estamos usando «instalación externa» para esta palabra).
Los traductores tienden a transliterar las frases. Esto resulta muchas veces en una traducción que, como se ha expuesto anteriormente, causa un español extraño y con poco sentido.
Por todas estas razones se concluye que no se pueden usar estos servicios de manera satisfactoria y desafortunadamente no podemos recomendar su uso.
A continuación se expone una tabla con posibles errores comunes que se suelen escribir a la hora de hacer traducciones al idioma español, con su corrección y notas del razonamiento.
Tips for getting your pull requests reviewed
Your PR description should make it easy for a reviewer to know what they are reviewing before they see the code. To avoid wordy descriptions, use bulleted lists to describe changes. When appropriate, add a screenshot or a short video that makes your change more obvious. Good descriptions cut time on the time a reviewer needs to invest and makes your PR more attractive.
If it's not obvious, it can also be helpful to include instructions on how to test your PR, including any pre-requisites or dependencies.
When you have your initial version for the proposed change working, look at your changes once again and ask yourself if anything could be improved before marking it "Ready for Review". Be sure to check that:
✅️ Your branch adheres to the elementary
✅️ No New Terminal warnings are introduced
✅️ Your branch passes required
If you need help or your branch isn't quite ready for review, you can open a Draft pull request and convert it to "Ready for Review" later
The most helpful advice for getting your code reviewed and merged quickly is to keep your diff as small as possible. Small diffs are less intimidating for reviewers, easier to test, easier to read, and have a much smaller chance of regression.
When proposing big changes, breaking up your work into several smaller pull requests is still considered best practice. Consider linking to an issue or discussion that explains the overarching goal.
It can be tempting to refactor code as you go, but this can make it harder for a reviewer to see what has been changed in your branch. If you need to refactor some code in order to make your change, consider submitting multiple PRs or separate refactoring commits from functional change commits and make it clear that you've done this in your pull request description. This extra step makes it much easier for another person to review your changes and minimizes the risk of regression.
Naming is one of those things that feels trivial but really helps in a few years when it's all new eyes on some code. It can make it much easier to figure out what's happening if we use names that are self explanatory and not too generic, especially if the names feel similar to those used in platform libraries like GLib and GTK.
Code comments should be used any time it's not immediately clear why something is being done. Comments shouldn't be used to describe obvious changes.
Aquí va a encontrar un glosario general de términos para diferentes usos y nobres en elementary OS.
A continuación se encuentra una lista de términos generales que pueden aparecer a lo largo de los varios proyectos de elementary. Se conservan aquí para obtener un estándar de base para todas las aplicaciones.
Los nombres de las teclas en español son diferentes a las del inglés y deben traducirse. A continuación se ofrecen las traducciones comunes para las teclas modificadoras del teclado y el ratón.
En elementary no estamos traduciendo todos los términos técnicos al español, dado el uso extenso de algunos en inglés y comúnmente aceptados.
Sin embargo, una de las reglas es tratar de traducir la mayor cantidad de términos (así sean menos conocidos), siempre y cuando sea claro el significado o si existe una palabra aceptada, así no sea muy popular.
Si no existe un término aquí, es recomendado hacer una búsqueda por el diccionario de Microsoft para encontrar un equivalente. De no haber uno, se recomienda entonces, en la medida de lo posible, encontrar un uso conocido en algún programa de amplio uso, o encontrar una traducción apta.
Hay términos que en ciertos contextos no tienen una traducción satisfactoria, y eso está bien. El punto es tratar de que la mayoría de los términos tengan su equivalente, pero no esperamos que sea posible para todos.
A continuación se muestra una tabla de todos los nombres propios de las aplicaciones y servicios de elementary
*Para estas aplicaciones, es importante notar cuando se está usando la palabra como el término común, o si se está refiriendo a la aplicación como tal.
A continuación, se presenta una tabla con los nombres de todos los complementos o «plugs» de la aplicación Switchboard.
*Al ser ambos nombres propios, tanto Dock como Panel tienen mayúsculas en este contexto
Es de notar que todos los plugs conservan sus nombres propios al hablar de la configuración de los mismos. Es decir, al utilizar «Configuración de...» como prefijo del plug.
Por ejemplo, «Sistema» sería «Configuración del Sistema», y «Fecha y hora» cambiaría a «Configuración de Fecha y hora»
A continuación tenemos una serie de buenas prácticas que pueden ser de utilidad a la hora de traducir al español.
Esta guía se creó para ser consultada y utilizada activamente, así como para ser modificada con nuevas palabras, buenas prácticas y advertencias de posibles errores. ¡Lo invitamos a usarla! Puede comenzar por la
Correr para hacer traducciones puede ser agotador y un poco frustrante. Este es un trabajo comunitario y voluntario, y las personas que lo hacen van y vienen. Los intereses y prioridades de cada quien cambian y puede que no halla nadie más que uno para hacer el trabajo.
También es posible que hagas sugerencias y alguien más decida tomarla o rechazarla.
Está bien, no es necesario apresurarse, sentirse presionado o pensar que lo ha hecho mal. Es un trabajo de todos y la idea es pasarlo bien. Tómese las traducciones con calma y tómese su tiempo para hacerlo bien y con gusto.
En Weblate, las sugerencias siempre son bienvenidas y también es más que bienvenido comentar en una traducción en específico con preguntas o aclaraciones para poder tener completa colaboración entre los integrantes de la traducción.
Las guías base encontradas en la son importantes porque tiene años de experiencia de muchas personas en unificar, aplicar coherencia y sencillez a traducciones de muchos proyectos complejos de software.
Por lo tanto, se recomienda consultar tanto esta guía como sus guías base para tener todas las referencias a la hora de traducir. Sin embargo, es de notar que, si existen contradicciones entre las guías base y esta, esta guía tiene precedencia sobre las guías base.
El buscador de Weblate puede ser muy útil para encontrar traducciones similares o de términos que pueden ya existir en otro proyecto.
No es necesario siempre tener que «inventar» la palabra o quemarse las pestañas encontrando la traducción correcta si ya alguien lo ha hecho antes con palabra y expresiones simples.
Es importante tener esto en cuenta para mantener la consistencia y coherencia del español en todos los proyectos y poder replicar las mismas formas y expresiones en otras partes de las diferentes aplicaciones.
Localizing our website and apps is an important part of making elementary OS available to as many people as possible. Instead of relying solely on an internal translation team, we use crowdsourcing so that anyone can submit translations with little to no technical knowledge. In order to keep our voice consistent across the entire platform, and to help new translators get started, we’ve put together this translation guide.
Our apps and website are translated through Weblate: A libre web-based translation management system. In order to submit translations, you should:
Have a
Set your
Browse our
Once you’ve selected a project, you can provide suggestions for strings that have not yet been translated, or suggest changes to strings that have already been translated. These suggestions will be evaluated by a translation team member and they will choose the most appropriate one. For more information about Weblate, you can refer to its .
By default, you will only be able to suggest translations. If you would like permission to save translations directly, and message an admin your Weblate username and the language you want to translate.
When translating you may encounter a situation where you have to decide between several ways of saying the same thing. In these situations we refer to the Ubuntu , and for language specific issues, we follow Ubuntu's . Following these guidelines ensures uniform translations, while also allowing anyone to contribute.
Some language teams have created guides specific to their language to support their own translation efforts. You can check a list of the current available guides here:
Each style guide will use their own language to explain their details. Expect these pages to not be available in English.
If you don't want to translate using Weblate, or want to make a lot a changes at once, you can also translate offline. To do so:
Go to a project you want to translate
Choose your language
Click on "Files" and then select "Download translation as gettext PO"
Start translating
Once you've finished, use the "Upload translation" option in the "Files" menu on the same page you downloaded the po files from
Some projects have been excluded from translations for technical or logistic reasons.
Developer and contributor facing documentation is excluded since developers and contributors will need to be able to read and write in English to do their work.
The elementary store is excluded since product information is only stored in English on the Printful platform, so it cannot be translated.
Puede consultar un glosario de términos de todos los nombres propios de las aplicaciones básicas de elementary OS en el .
Es bastante común caer en la tentación de utilizar servicios de traducción como para obtener una traducción rápida.
Proposed changes should generally only implement things that are actually needed right now, not just when you foresee that they may be needed in the future. This is known —You aren't gonna need it. Combined with continous refactoring, the YAGNI principle keeps the code base as simple as possible while helping us to avoid technical debt.
It's possible to clean up your Git history after the fact with .
Esta tabla la tomamos de la «Guía de estilo de Ubuntu al español»:
Una buena parte de estas palabras que hemos traducido parten del diccionario informático .
Choose your favorite text-, code- or PO-editor (e.g. )
Click with the secondary mouse button
Haga clic con el botón secundario del ratón
Haga clic con el botón derecho del ratón.
Existen usuarios que usan el ratón con la mano izquierda, así que el botón derecho se refiere al botón secundario (la excepción es cuando explícitamente se refiera al botón físico del ratón). Las acciones de un botón son primario, secundario y central.
Whoops! That link has expired!
¡Vaya! ¡Este enlace ha caducado!
Vaya! Este enlace ha caducado!
Las frases de interrogación y exclamación siempre llevan signos tanto al comienzo como al final de la frase expresada.
We Have Shipped Your Order
Hemos enviado su pedido
Hemos Enviado Su Pedido
Las mayúsculas compuestas no se permiten en español (esto es, una mayúscula al inicio en cada palabra). Sin embargo, se debe tener cuidado de no descapitalizar un nombre propio. Las siglas tampoco de descaptilizan
Spring, Fall, March, November, Tuesday, Friday
Primavera, otoño, marzo, noviembre, martes, viernes
Primavera, Otoño, Marzo, Noviembre, Martes, Viernes
Los días, meses y las estaciones no utilizan mayúsculas en español, a menos que comiencen una frase
"elementary OS is different… a beautiful and powerful operating system."
«elementary OS es diferente… un sistema operativo hermoso y potente».
«elementary OS es diferente… un sistema operativo hermoso y potente.»
Los puntos siempre van por fuera de las comillas y los paréntesis en español.
System Settings offers several advantages to OEMs shipping elementary OS.
La Configuración del Sistema posee varía ventajas para fabricantes OEM que ofrezcan elementary OS.
La Configuración del Sistema posee varía ventajas a las OEMs que ofrezcan elementary OS.
Las siglas no tienen plural en español, si ver siglas plurales, se debe buscar una alternativa o, como mínimo, utilizar los determinantes plurales (los, las).
Click
Clic
A pesar de que «pulsar» es correcto, se prefiere «clic» o «hacer clic» en lo posible
Manage, manager
Gestionar, gestor
Se puede usar «administrar» pero se prefiere primero ver si «gestión», «gestor» o «gestionar» funciona bien en el contexto.
Management
Administrar
Se la misma manera que manage, si desea usar «gestionar», asegúrese de que suene bien en contexto.
Toggle
Activar o desactivar
Nótese que es toda la frase «activar o desactivar». Es posible usar «mostrar u ocultar» «alternar» o «intercambiar» si el contexto lo amerita.
Always on top
Siempre visible
Evitar usar «siempre encima»
App
Aplicación
En ningún contexto usaremos la acepción «app» o cualquier otra abreviatura en español
Daemon
Servicio
En el mundo Linux es común usar daemon o «demonio» en español. Sin embargo para un usuario final en español es más común usar «servicio» como término universal
Icon
Icono
Nótese que estamos utilizando la acepción que no tiene tilde
Wallpaper
Fondo de escritorio
Accent color
Color de énfasis
Multitasking
Multitarea
Portal
Portal
Relativo al sistema de portales de flatpak. Dependiendo del contexto se puede usar como nombre propio
Plug
Plug o complemento
Relativo al sistema de complementos de elementary para Switchboard. Los plugs son el nombre interno de estos elementos de configuración.
Setting
Configuración
Para el usuario, se usa de manera general de la misma forma que en inglés settings, traducido a «Configuración de...» (por ejemplo, «Configuración de Bluetooth») internamente se sigue usando «plug» como nombre interno
Stylus
Lápiz o lápiz digital
Device
Equipo o dispositivo
En elementary en español estamos haciendo la distinción de «equipo» que se usa al refersire al computador mismo. «Dispositivo» se usa para cualquier otro dispositivo externo que no sea el computador
Terminal
Terminal
Por lo general usamos la acepción masculina (el terminal). Pero no hay ningún problema en usar la acepción femenina (la terminal) si el mensaje lo amerita o se siente mejor en la traducción.
Command, Commands
Comando, comandos
Evitar la acepción «orden»
Shell
Intérprete de comandos
Existen excepciones para ciertos casos, como SSH (Secure Shell) o si no es claro cuando Shell signifique esto. Existe una excepción al referirse a entornos de escritorio (tal como desktop shell, o Patheon desktop shell), en el cual usaremos «entorno de escritorio»
Runtime
Entorno de ejecución
Dekstop runtime
Entorno de escritorio
Esto es igual a desktop shell en inglés. Aunque técnicamente lo correcto es «entorno de ejecución de escritorio», es demasiado largo y comúnmente se omite la palabra «ejecución» para el escritorio
Date & Time
Fecha y hora
En español nunca se utiliza el símbolo «&» para conjunciones, a menos que sea parte ineludible de un nombre propio
Sharing
Uso compartido
Esto es en el contexto de compartir archivos, imágenes, música y otros contenidos con otros dispositivos en la red
Hardware
Hardware o dispositivo(s)
Es preferible utilizar la palabra «dispositivo(s)» si tiene sentido utilizarla en el contexto.
Software
Software o aplicación/aplicaciones
Es preferible utilizar la palabra «aplicación» o «aplicaciones» si tiene sentido utilizarla en el contexto.
Hot Corner
Esquina activa
Workspace
Área de trabajo
Display
Pantalla
Se puede utilizar «monitor» cuando se refiera exclusivamente al dispositivo físico como tal. En cualquier otro contexto, se usa «pantalla». Es decir, display resolution se traduciría como «resolución de pantalla», no «resolución de monitor».
Refresh Rate
Frecuencia de actualización
Aspect ratio
Relación de aspecto
Home folder
Carpeta personal
Esto es relativo a la carpeta personal de cada usuario para guardar descargas, documentos, imágenes, video, música, etc. Específicamente es la dirección /home/nombre-de-usuario/ en el sistema de archivos
Streaming
Transmisión, transmitir
Locale
Configuración regional
Es posible decir «región» o «regional» si la traducción lo amerita para evitar textos muy largos o redundantes
Maximize
Maximizar
Unmaximize
Restaurar
Evitar el uso de «deshacer maximizado» o «desmaximizar»
Website
Sitio web
En general se prefiere «sitio web», pero es posible usar «página web» si el contexto lo amerita
Primary mouse button
Botón primario del ratón
Secondary mouse button
Botón secundario del ratón
Right mouse button
Botón derecho del ratón
Left mouse button
Botón izquierdo del ratón
Middle mouse clic
Clic del botón central del ratón
Click
clic
Double click
Doble clic
Alt
Alt
Alt Gr
Alt Gr
Backspace
Retroceso
Caps Lock
Bloq Mayús
Ctrl
Ctrl
Del
Supr
End
Fin
Enter
Intro
Esc
Esc
Home
Inicio
Ins
Ins
Num Lock
Bloq Num
Pause
Pausa
SysReq
Pet Sis
PgDn
Av Pág
PgUp
Re Pág
Print Screen
Impr Pant
Scroll Lock
Bloq Despl
Shift
Mayús
Spacebar
Barra espaciadora
Space
Espacio
Tab
Tab
AppCenter
Centro de Aplicaciones
Calculator
Calculadora
Calendar
Calendario*
Camera
Cámara*
Code
Code
Se conserva el nombre original en concordancia con otras aplicaciones que hacen algo similar, como por ejemplo Microsoft VS Code
Files
Archivos*
Correo*
Music
Música*
Photos
Fotos*
Screenshot
Captura de Pantalla*
Shortcuts
Atajos*
Tasks
Tareas*
Terminal
Terminal*
Feeback
Comentarios*
Videos
Videos*
Estamos usando el vocablo sin tilde, que es válido en español y cumple con el español internacional sobre «vídeos»
Web
Web*
Epiphany
Epiphany
El nombre antiguo (ahora interno) del navegador web de GNOME, conservamos el nombre original y no se traduce
Installer
Instalador*
Conocido también como «Instalador de elementary»
Onboarding
Bienvenida
Multitasking
Multitarea*
Conocido también como «Vista Multitarea» (nótese la V mayúscula)
Multitasking & Window Management
Multitarea y gestión de ventanas
System Settings
Configuración del Sistema*
Switchboard
Nombre interno de la herramienta de «Configuración del Sistema». No vemos motivo para cambiarlo, ya que es un nombre interno y los programadores preferirían verlo así.
Sideload
Sideload
No hay una traducción completamente correcta para esta aplicación. Lo más cercano es «transferencia local» pero no representa correctamente como se usa en elementary. La palabra ordinaria utilizamos «instalación externa»
Wingpanel
Wingpanel
El nombre interno de «Panel» que conservamos en inglés
Panel
Panel
El nombre interno del programa es Wingpanel, pero en la documentación externa de le conoce como Panel que traducimos directamente al español
Dock
Dock
Se ha propuesto antes «Lanzador», pero por ahora hemos consideramos que Dock se conserve
System Settings
Configuración del Sistema
Settings Daemon
Servicio de Configuraciones
Applications Settings
Configuración de Aplicaciones
Desktop Settings
Configuración del Escritorio
Display Settings
Configuración de Pantalla
Sound Settings
Configuración de Sonido
Keyboard Settings
Configuración de Teclado
Dock & Panel
Dock y Panel*
Language & Region Settings
Configuración de Idioma y región
Date & Time Settings
Configuración de Fecha y hora
User Accounts Settings
Configuración de Cuentas de usuario
Notifications Settings
Configuración de Notificaciones
Network Settings
Configuración de Red
Security & Privacy Settings
Configuración de Seguridad y privacidad
Sharing Settings / Sharing
Configuración de Uso compartido / Uso compartido
Bluetooth Settings
Configuración de Bluetooth
Screen Time & Limits Settings
Configuración de Tiempo en pantalla y límites
Wacom Settings
Configuración de Wacom
The fastest way to get a collection of common app dependencies and developer tools is to install elementary-sdk from Terminal:
You can quickly install all known dependencies for a project with build-dep:
This installs the dependencies for the currently-released version, so it may miss dependencies for unreleased updates. In those cases, refer to the project's README.
To make it easier to follow the elementary Code-Style guidelines you can use vala-lint.
The GTK Inspector is similar to a web browser's inspector, but for GTK apps. Using the Inspector can greatly speed up development, and allows you view and to test out changing properties without recompiling an app. You can also test out temporary in-app CSS.
First, make sure you have elementary-sdk installed. Then enable the Inspector keybinding:
Focus an app, then launch the Inspector by pressing Ctrl+Shift+I to inspect the widget beneath your cursor, or Ctrl+Shift+D to open the inspector without a widget selected.
You can also run it temporarily together with an app by running:
You can audit your system for files that have been changed from their originally installed packages:
View changed files:
View which packages those files belong to:
Assuming that you've used --prefix=/usr when installing custom version you can restore them using:
Gala is the window manager of elementary OS. If it crashes or freezes during development, it can be nonobvious how to recover. Here's how to do it:
Go to one of the virtual consoles by pressing: Ctrl+Alt+F1
Log in
If Gala didn't crash but froze, you can kill it by running killall gala
Restart Gala by running DISPLAY=:0 gala --replace &
Switch back to the graphical session by pressing Ctrl+Alt+F7
If Gala doesn't start, you can reinstall the latest stable version by running sudo apt install --reinstall gala.
elementary uses GitHub to track issue reports and feature requests publicly. You can send feedback to the team to inform us of a problem you encountered or an improvement that you would like to see.
To get started with issue reporting, open "System Settings" and navigate to the "System" page. Select "Send Feedback", which will open the Feedback app. From here, choose a category that best describes the general area of the issue, and then choose a specific project to open a new issue against. This will open your web browser to the relevent GitHub page where you can view and create new issue reports.
If you can't find a specific project or aren't sure which project to file against, that's okay! Do your best and if the issue report needs to be migrated to a different project, a bug manager will take care of it for you.
You can also see a list of all elementary Github projects on this page and search for projects here. When you've found the project you'd like to open a new report against, open it and then select the "Issues" tab.
When filing a new report, it's a good idea to search the issue list to make sure your report hasn't been filed already. If your report has already been filed by someone else, you should add the 👍️ reaction to the report to indicate that you are also affected.
Only comment on an existing issue report if you can provide additional useful information that may help track down the source of the issue. Do not comment things like "I have this problem too" or "This is a really important issue"
If your report has not already been filed, select the green "New Issue" button at the top right corner of the "Issues" page. Keep in mind the following information while filing your report:
This will be the title of the issue on the issues page. It's important to be specific because it makes it much easier for a developer or bug manager to search the issue list and helps avoid duplicate reports.
❌️ "Performance is bad"
This summary is too vague and could possibly describe a number of different issues.
✅️ "UI is unresponsive while importing"
This summary describes the specific case where we're experiencing a performance issue and what that issue is in a concise way.
Your issue summary should also not include things in brackets like "[bug]" or "[feature request]". elementary uses labels to categorize issue reports.
The most important thing for an issue report is making sure that a developer will be able to understand and reproduce the issue that you're facing. Describe what happened and contrast it with what you expected to happen instead. If necessary, include exact numbered steps to reproduce the issue.
❌️ "Queuing is unintitive. I don't like the way it works"
This description leaves too much room for interpretation and doesn't specifically describe a problem that can be resolved.
✅️ "When I add items to the queue, they appear at the top. I expected them to appear at the bottom instead"
This describes a problem in a way that is actionable and objective and explains how to reproduce the issue.
Include relevant information like your OS version or any modifications you've made to the system (like changing your window manager or kernel). If you're reporting a crash, make sure to include a backtrace.
If your report does not contain enough information for a developer to reproduce the issue, it may be labeled as "Incomplete". If it is, a developer will make a comment requesting additional specific information. If you do not provide that information, your report will eventually be closed since it is unable to be acted upon as filed.
If you're not sure about anything above, you are always welcome to chat with community members and developers in Discord. We might be able to help you track down the project where you should report an issue, or perhaps even aid you with any English language issue you might come across. Most developers want to help you make good bug reports.
elementary uses GitHub Issues both for reporting problems and for tracking feature requests. In addition to what's been mentioned in Reporting Issues, keep in mind the following tips when creating new feature requests:
It's often tempting when creating a feature request to only describe the proposed solution, but don't forget to fully describe the problem that your proposal is meant to solve. Describing the problem is an essential step to ensure that a proposed design meets its goals.
If you're having trouble describing the problem in a concise way or it involves a larger design change rather than a single new feature, consider starting a discussion instead
If you can, include a mockup or a sketch of what your proposed new feature would look like. Or, if there's another project that implements this feature, include screenshots or links to that project.
If there could be alternative solutions to your intial problem, describe them and their merits. A developer may decide that a certain specific feature request is out of scope for a project or conflicts with its other design goals, but if you include alternative solutions one of those may work better and be accepted as a solution.
The GNU Project Debugger (gdb) is a general purpose debugger, but we're mostly going to focus on getting useful information when an application crashes. To get started, open an application in gdb, for example AppCenter by running:
Now run this application by typing run and pressing enter.
If the application doesn't crash right away try reproducing the crash.
Get more information by typing backtrace and pressing enter.
Please share the lines after (gdb) backtrace, those should provide useful information.
For more information see the manpages by running: man gdb. Another tutorial: Debugging with GDB
Running the application under gdb slows down the application and is problematic to reproduce some crashes. In such cases, it is recommended to use the systemd-coredump service which will gather application information on crash.
Let's take our example above of AppCenter: if the application would have crashed without understanding what might have happened, the service would retain the backtrace which is then replayable with:
If there are lines such as 0x00001234deadbeef in ?? () it means that we are missing some debugging symbols.
The debugging symbols of elementary OS are hidden by default (as they are taking some space). To be able to discover then, we need to add their corresponding debian source:
We can then install all the missing debugging symbols with:
Rerunning coredumpctl debug should now show more useful traces.
For a flatpak application, we can use flatpak-coredumpctl io.elementary.elementary.calculator to see the latest traces of a crash inside flatpak.
elementary uses GitHub to not only track issue reports but also for planning improvements and design changes.
If you want to start a larger conversation around a design change that could incorporate many smaller changes or needs some discussion before it can be actionable, you can use GitHub Discussions.
As described in Reporting Issues, you can use the Feedback app to find and open the relevant project page to start a new discussion or you can manually search for projects on GitHub. When you've found what looks like the right project, head over to the "Discussions" tab and select "Ideas" in the sidebar to see design proposals and conversations.
Just like when reporting issues, please search open discussions to see if you could be participating in an already open discussion before creating a new one.
To start a new discussion, select the green "New discussion" button in the top right and keep these tips in mind:
A good design proposal should have clear design goals and often these can be expressed as GitHub issues. Referencing issues that should be considered and solved within the scope of this design discussion helps guide the direction of discussion and gives developers a way to start working towards solutions. Creating new issue reports as part of the design process can also have a few other benefits:
It will make your design proposal less intimidating. A big design proposal can mean a big time investment that will likely have to be taken on by someone volunteering their free time. Smaller changes that can be incorporated over time are more likely to be adopted and resolved
It allows developers to track their progress. Even if a developer wants to implement your entire proposal right away, they might not be able to. Giving them a way to “check off” pieces as they go makes it more likely that a part of your design won’t be forgotten about when it’s translated into code.
It allows developers to scope down your proposal. It's possible that some part of your proposal doesn't fit within the project scope or conflicts with another part of its design. Breaking up your overall proposal into smaller action items increases the change that at least some part of your proposal will be incorporated, even if other parts of it can't be.
Designers are often opinionated and passionate people, but please try to remember that developers are people too. It's important to be objective about the current design of a project, but try to avoid disparaging others' work and keep in mind the Code of Conduct. The outcome of a design discussion should be exciting and inspiring and is an opportunity for collaborative problem solving.
If part of your proposal conflicts with an existing project goal or is considered out of scope, you might have to go back to the drawing board a bit! Developers may provide feedback that means your idea needs to change a little bit before it can be worked on. Designs can often go through many revisions or take some time before everyone is happy and work can begin.
Everything that we make is 100% open source and developed collaboratively by people from all over the world. Even if you're not a programmer, you can get involved and make a difference.
Looking for documentation on creating your own apps? See Developer Documentation instead.
elementary OS is created and used by people from all around the World; help us make the experience even better by translating it into more languages. Both elementary OS and our website are openly translated using an online platform called Weblate
Our desktop environment and all its apps are built using Vala, Gtk, Granite, and a number of other open libraries. We host all of our code and do all development openly on GitHub.
We release updates every month with new features and bug fixes based on the feedback that is reported to us on GitHub. Report Issues, request features, and start discussions directly with the developers and designers that make elementary OS
Many apps will create logs for various types of errors with additional information that a developer can use to locate the source of the issue. Including those logs in your issue reports when you experience a problem can help solve the problem faster.
To view existing logs from all your applications you can use journalctl``
By default, debug messages are not shown since they can be quite noisy in normal usage. To see debug logs, start the app from Terminal using the environmental variable G_MESSAGES_DEBUG
If the app in question is a Flatpak app, like the apps available from AppCenter, you'll need to start the app with flatpak run as well:
Now that logs are being printed to Terminal, reproduce the issue you're experiencing then copy and paste the Terminal output to the bottom of your issue report.
For information on creating logs in your app, see the developer guide