-
Notifications
You must be signed in to change notification settings - Fork 19
traducción "repository" y otros términos de Git #40
Comments
hola! no, parece que 'repository' no está en las convenciones de traducción mi opinión es que en este caso estaría mejor traducirlo porque la palabra es muy similar y el significado se conserva |
muchas gracias, @agbeltran! qué sugieres con el resto de los términos que menciono? yo veo tu punto sobre el parecido de repository, pero a su vez me parece que traducir términos de github iría en contra de la convención más general que parece haberse adoptado con respecto a estos términos que es no traducirlos. Ojalá otras personas sumen su opinión por acá sobre esto así desambiguamos 😸 |
Me sumo a traducir repositorio. Los terminos fork, pull request y master no. Issue podría traducirse pero creo que ahí si aplica lo que mencionas Laura. |
Entiendo tu comentario sobre mantener el mismo criterio para toda la familia de términos. Pero pensando en el día a día, nunca usé "repository" como dice Yani. Capáz es algo muy de Argentina! |
Gracias!! Je, buen punto! Veamos si alguien de fuera de Argentina confirma esto. |
Hola, opino:
y no traducir "fork", "pull request", "issue", "master", "branch", "commit", "push", "actions", "README", "merge", ".gitignore", "git init", "fetch", "Staging area", "upstream" Aqui hay una buena referencia, con un glosario en espanhol. Al final hay enlaces a otras referencias. |
Yo estoy de acuerdo con lo que dice @orchid00 en cuanto los comandos, pero "fork", "issue", "actions", "README", "staging area" y "upstream" no son comandos. Incluso, "pull request" casi tampoco. Yo optaría por usar lo que otros ya han traducido. Por ejemplo, gitlab tiene una versión en español. En su glosario tienen:
Y yo añadiría:
En la página tienen el siguente comentario:
Y creo que es ahí el punto que tenemos que conseguir nosotros. No traducir el comando en sí, pero usar el vocabulario en español cuando nos referimos a ellos. De otro modo, "merge" no lo voy a entender como si me dices "fucionar". |
Otro recurso que nos viene muy útil: el libro de git, ¡en español! |
Y ellos también tienen un glosario. |
Creo que estamos de acuerdo en no traducir los comandos. Con respecto de la explicación de los términos, estos no me resultan "naturales": fork - bifurcación: no sería mas como una copia? Coincido que se llama LEEME...se usa mucho en los repo en español??...en general veo que igual le ponen README... Pedido de tirar: no me ayuda en nada a entender....preferiría no traducirla y no meter otro concepto más a un tema que de por si, es complejo. O bien buscar otra alternativa (no se me ocurre ninguna ahora) Creo que tenemos que tener en cuenta que si la persona va a buscar más ayuda/material/cursos sobre el tema tiene que poder usar los términos que le permitan encontrarla y si usamos palabras o frases que son pocos comunes vamos a complicar esta actividad. Tampoco vamos a resolver lo antinatural que resulta git porque lo pasemos al español...yo vería como explicamos el concepto lo mas claro posible en español y le damos el nombre que tiene en inglés y con el que se va a encontrar el usuario en la terminal, en la web, en la interfaz de escritorio, en los foros.... Linda discusión!!! |
Solo un comentario sobre README. No estoy segura si github necesita que ese archivo se llame explicitamente README.md para mostrarlo como documentación del repositorio en cuestión. Si esto es así, me resulta raro traducirlo a LEEME si luego van a tener que nombrar al archivo como README. Capaz estoy equivocada, pero creo que puede ser importante! |
Desde mi opinan "Mexicana", estoy completamente de acuerdo contigo David.
Efectivamente folk, si bien es una copia, es una copia "que bifurca".
El lun., 27 ene. 2020 a las 17:24, David Pérez-Suárez (<
[email protected]>) escribió:
… Yo estoy de acuerdo con lo que dice @orchid00
<https://github.com/orchid00> en cuanto los comandos, pero "fork",
"issue", "actions", "README", "staging area" y "upstream" no son comandos.
Incluso, "pull request" casi tampoco.
Yo optaría por usar lo que otros ya han traducido. Por ejemplo, gitlab
tiene una versión en español. En su glosario
<https://translate.gitlab.com/translate/gitlab-ee/10/en-es> tienen:
- branch - rama
- fork - bifurcación
- remote - remoto
- staging area - area de preparado
- unstaged changes - cambios sin preparar
- merge - fusionar
- push - enviar
- pull - tirar
Y yo añadiría:
- README - siempre a sido LEEME
- pull request - ellos no tienen de esto, pero una "merge request":
pedido de fusionado. 'pull request' es, en si mismo, díficil de entender
para los que hablan inglés... y hasta que no entiendes como funciona git...
no le pillas el significado. Pedido de tirar?
En la página tienen el siguente comentario:
The context : Git terms and defaults should generally NOT be translated,
unless being used to explain a git concept. This helps maintain consistency
between GitLab and the git client.
Y creo que es ahí el punto que tenemos que conseguir nosotros. No traducir
el comando en sí, pero usar el vocabulario en español cuando nos referimos
a ellos. De otro modo, "merge" no lo voy a entender como si me dices
"fucionar".
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#40?email_source=notifications&email_token=AEYEBZOIORRDBROZH5JBMSTQ75UMRA5CNFSM4KJTF4AKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKBORDI#issuecomment-579004557>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEYEBZLHONIUCSOJJTCHFQLQ75UMRANCNFSM4KJTF4AA>
.
--
VERONICA JIMENEZ JACINTO
Unidad de Secuenciación Masiva y Bioinformatica.
Instituto de Biotecnologia
Universidad Nacional Autonoma de México.
www.uusmd.unam.mx
|
@paocorrales si tiene q llamarse README para qué lo reconozca. Dentro del docu puedes escribir en español sin ningun problema y poner titulo leeme. |
@lauracion nosotros ya traducimos la leccion de git https://carpentries-es.github.io/git-novice te parece q ahi hay inconsistencias q hay q cambiar ? O solo era curiosidad la pregunta? |
Yo soy peruana y digo siempre repositorio. Pero hablo de "commit", "pull" y "push" la mayor parte del tiempo. La traducción hecha en https://carpentries-es.github.io/git-novice me parece bastante entendible, usando los términos sin traducir. Se podría colocar eso en la convención de traducción. |
Sí, pero es una copia sólo en el momento que haces el clon, después ya no sigue el mismo camino. El README, como fichero para que GH lo muestre, entonces sí, tiene que ser tal cual (con cualquiera extensión). Pero, como fichero que pones dentro de tu repositorio para que sea la primera cosa que tus compañeros abran... entonces LEEME es más obvio. ¿Se usa? Pues en antaño yo recuerdo de descargarme programas que tenía que compilar y tenían sus LEEMEs, hoy en día sólo se me ocurre buscar en github y me da sólo 700 archivos, y de los que he mirado todos tienen también un readme en el repositorio (posiblemente porque es el que GH muestra). Tanto en github como en gitlab no he encontrado si hay la manera de elegir qué fichero mostrar. Anecdoticamente, por allá en antaño... junto con los README, INSTALLME, etc.. había proyectos que también tenían TODO donde incluían las instrucciones para instalar y ejecutar dichos programas. No fué hasta hace poco que me llegó la luz... y vi que TODO no significaba "todo" lo que había que hacer, sino que era todo lo "que había que hacer"!!! 🤯 (orgasmo mental!) |
David yo tuve diskettes (de 5 1/4) con leeme.txt dentro 😉😁....hablando antaño...jejejeje (igual soy muy jovencita...sólo que inicié muy pequeña mi camino por la computación 😂😝) Entendido lo del fork 👍 |
Ey! Qué buena toda la discusión! Muchas gracias por todas las contribuciones, muy valiosas todas. @orchid00 la idea es justamente no contradecir el trabajo ya hecho. En las convenciones de traducción (gracias por el link, Alejandra!) está la convención de no traducir la mayoría de los términos de git, pero no se listan los que indicaba inicialmente. Mirando la lección de git, parece que los términos que aún no tienen convención de traducción establecidos no fueron usados, salvo por Estas dudas me surgieron cuando traduje la sección de cómo contribuir en la lección de instructor training. Allí aparecen términos como fork y repository y el resto que menciono, y que no encontré en la lección de git. Entiendo que el consenso que surge es traducir "repository" a "repositorio" y mantener el resto de los términos git-related en inglés como se hizo hasta ahora en la lección de git ya traducida. Si alguien no acuerda con esto que yo veo surgir de la mayoría que opinó y de lo hecho anteriormente, por fa avise. Si no, la semana que viene cierro este issue, incluyo los términos en las convenciones y lo doy por resuelto. Gracias! Muy buen fin de semana, gente! |
Hola,
no encuentro mención de si hay que traducir o no "repository". Lo mismo para "fork", "pull request", "issue" y "master". Por otros términos como "branch" y "commit" parecería que son de las que no se traducen.
Qué opinan?
Gracias!
The text was updated successfully, but these errors were encountered: