Skip to content
This repository has been archived by the owner on Jan 20, 2022. It is now read-only.

Traducir documentación de la API #73

Closed
SametSisartenep opened this issue Feb 22, 2015 · 48 comments
Closed

Traducir documentación de la API #73

SametSisartenep opened this issue Feb 22, 2015 · 48 comments

Comments

@SametSisartenep
Copy link

Estoy pensando en traducir la documentación de io.js en su versión actual (1.3.0) e ir añadiendo los cambios conforme a su evolución.
Por el momento cuento con @eafelix para ello, aunque espero que se apunten más personas :)

@soybackend
Copy link

+1 Me apunto, ¿donde la pondrás? ¿La dividirás en secciones, por documentos o en uno solo?

@eafelix
Copy link

eafelix commented Feb 22, 2015

aca esta la lista de items de la documentacion.

sobre esto deberíamos dividirnos

@SametSisartenep
Copy link
Author

La verdad es que esta es la primera vez que contribuyo en temas de traducción, ¿cuál es la mejor forma de estar coordinados, o qué plataforma soléis usar?

@eafelix
Copy link

eafelix commented Feb 22, 2015

Podemos abrir un repo que se llame io.js-api-es y sobre ese tener un branch api-es y commit ahi.
pero antes me gustaría ver como están en los otros idiomas manejando esto así nos alineamos con el ellos.

por otro lado, somos 3, un total de 39 items de los cuales deberíamos traducir 13 items cada uno.

Que opinan?

@SametSisartenep
Copy link
Author

Comparto tu idea del repo. En cuanto a los items, podríamos ir escogiendo 3 o 4 para empezar, y vemos qué tal vamos, así si se unen más personas pueden comenzar sin problema.

@eafelix
Copy link

eafelix commented Feb 22, 2015

@SametSisartenep +1
Antes investiguemos como lo están manejando los otros idiomas el tema de la API así nos alineamos , para no crear el repo y después tener que migrar todo

@SametSisartenep
Copy link
Author

@eafelix Perfecto, voy a ello :)

@soybackend
Copy link

Vale a por ello entonces

@stringparser
Copy link

Yo me apunto también por aquí para ir traduciendo. Todavía estamos a la espera de nodejs/iojs.org#211, pero si queréis por mi podemos ir empezando. La idea de un repo separado no la comparto pero como vosotros habéis sido los que os habéis puesto a mirar esto, lo que mejor os parezca ;)

@eafelix
Copy link

eafelix commented Feb 22, 2015

@stringparser que idea tenias en mente?

@edsadr
Copy link
Member

edsadr commented Feb 23, 2015

yo se que a @stringparser no le va a gustar... peo yo sugeriria un repo en la organización iojs-es y usar transifex

@eafelix
Copy link

eafelix commented Feb 23, 2015

Genial, continuemos con transifex y el repo si lo desean.
Lo que crean mas comodo, me acoplo sin problema :P.

@SametSisartenep
Copy link
Author

Gracias por la referencia @stringparser .
La verdad es que me gusta la idea del repo, @edsadr , aunque no sé si deberíamos esperar a los demás para saber cómo piensan manejarlo en el sitio principal. De todas formas, podríamos comenzar nosotros y en cuanto recibamos un evento, cambiamos lo que haga falta :)

@stringparser
Copy link

Hhahahah, da igual @edsadr y @eafelix si mientras haya movimiento yo estoy encantado :). Perfect, usamos transifex y iojs-es.

@SametSisartenep
Copy link
Author

¿Qué tengo que hacer para unirme a vosotros en Transifex? Traté de unirme aquí, pero me rechazaron la petición.

@edsadr
Copy link
Member

edsadr commented Feb 23, 2015

@SametSisartenep te acabo de aprobar

@SametSisartenep
Copy link
Author

Gracias @edsadr .
Espero vuestras indicaciones :)

@eafelix
Copy link

eafelix commented Feb 24, 2015

Creo una carpeta en el root del repo q se llame API?
y sobre eso laburamos en transifex mas adelante?

@eafelix
Copy link

eafelix commented Feb 24, 2015

https://github.com/iojs/iojs-es/pull/77 @a0viedo ya comenzo con crypto. Vallan tomando de la lista que deje arriba cuales quieren traducir y los vamos subiendo bajo el mismo nombre en la carpeta api que cree en el root del repo

@a0viedo
Copy link
Member

a0viedo commented Feb 24, 2015

acá hay que ser rápidos cómo con la bolsa surtida de galletas, si no se apuran ya se van a ir los mejores 😛

@eafelix
Copy link

eafelix commented Feb 24, 2015

Streams es mio :p jua jua jua

@SametSisartenep
Copy link
Author

Genial, yo voy traduciendo "C/C++ Addons" :)

@SametSisartenep
Copy link
Author

Por cierto, ¿"Addon" es conveniente traducirlo? Es que creo que, al igual que "Plug-in", es una palabra cuyo significado se ha extendido muchísimo internacionalmente. No sé si "Añadidos" o "Extensiones" serían adecuados.
¿Qué pensáis?

@italoacasas
Copy link

Extensiones es posible, porque se entiende el significado, pero Añadidos realmente en este contesto no se entiende muy bien.

-1 Añadidos
+0.5 Extensiones
+1 Addons & Plugin

@italoacasas
Copy link

ok, yo empiezo con HTTPS, cuando tengas un time actualicen el listado.

@SametSisartenep
Copy link
Author

Gracias por la sugerencia @italoacasas , creo que mantendré "Addon" :)

Perdonad que pregunte tanto 😅 , pero ¿Puedo modificar el código de los ejemplos para hacerlo más "spanish-like"? Sé que el repositorio lo mantiene @rvagg aquí. La idea sería forkearlo como "ejemplos-addons-node" o algo similar y sustituir los enlaces en la documentación.

@eafelix
Copy link

eafelix commented Feb 24, 2015

Buena consulta para ya definir eso.
Yo lo acompaño la idea del spanish-like, pero si me gustaría que todos lo revisaremos con mas atención la traducción de la API que el resto debido a su gran importancia. Acá estaríamos definiendo y estandarizando muchas cosas hacia futuro (obvio todo sujeto a revisiones de todos).

@stringparser
Copy link

Yo traduciré este domingo, esta semana estoy liaete complicada

@ipeluffo
Copy link

Consulta y propuesta, creo que sería una buena idea crear un issue por cada sección de la Documentación de la API. De esta manera sería más fácil llevar un seguimiento de cómo viene cada traducción, ej. el issue puede ser asignado al usuario.

@stringparser
Copy link

+1

@italoacasas
Copy link

Las traducciones son algo complicadas, lo mas importante que hay que tener en mente es que no se deben utilizar términos de un pais en especifico.

Si hay las personas suficientes, se podrían crear dos equipos uno que traduzca y otro que compruebe, o hacerlo en duo, uno traduce el otro rectifica, si es posible el duo que sea de diferentes piases. feedback please

@a0viedo
Copy link
Member

a0viedo commented Feb 25, 2015

@italoacasas si, de más está decir que estaría genial un review después ya que es un léxico altamente técnico.

otra cosa, podríamos hacer un issue que sea "glossary discussion" o algo así? tengo muchas otras dudas cómo las de @SametSisartenep

@eafelix
Copy link

eafelix commented Feb 25, 2015

No me parece, y ya se discutió la traducción por países específicos.
Mismo tampoco con issues por cada modulo, para eso están los PR para que todos los revisemos sobre el contenido finalizado para ya acordar entre todos la estandarización de términos (implica la concordancia entre todos los miembros de los diferentes países lo cual la revision tiene mas concurrencia que un issue).
Un ejemplo, con amigos colombianos, chilenos o ecuatorianos nunca tuve problemas de terminologia, y si había diferencias eran obvias en la comprensión lo cual no había dificultad.

ahora en el README.md creo la lista y vamos chequeando las que estan tomadas y ponemos nuestro nombre al lado de las que tomamos
asi no abrimos issues a lo loco por cada uno.
A medida que vamos subiendo, los corregimos todos en el PR
les parece?

@a0viedo
Copy link
Member

a0viedo commented Feb 25, 2015

@eafelix yo creo que el workflow sería pasarlo a transifex y ahí hacer las revisiones necesarías, después hacer el PR desde la org iojs-es cómo mencionó @edsadr

@italoacasas
Copy link

@a0viedo yo realmente estoy a full con unos proyectos y organizando Nodeschool en Miami, etc y no estoy atendiendo mucho todo este tema, lo unico que voy a hacer es traducir unas horas semanales, lo demás, como quieran hacer las cosas me parece bien lo que decidan ustedes.

Sobre las traducciones creo que en transifex es la mejor alternativa, pero si quieren hacerlo con issue o PR, decidanlo para todos trabajar de una misma manera

@eafelix
Copy link

eafelix commented Feb 25, 2015

Como todos lo crean necesario, como a la mayoría le parezca mas comodo no hay problema. Pero el flow de como se va a dar la traducción debe reflejarse acá para no pisarnos en las traducciones (que dos tomen el mismo modulo) o que otros abran issues desacoplados o otros vallan por transifex, mas que nada esa es la preocupación, como tambien tener rastro de quien tomo que.

@SametSisartenep
Copy link
Author

Yo voto por Transifex y PR desde allí, como propone @a0viedo .

El caso es que no tengo práctica alguna con la aplicación, ¿Cómo es el workflow desde ahí?¿Subes el archivo y traduces en paralelo con el original?¿Traduces el texto al completo, párrafos, frases?
Voy a informarme mejor :)

@eafelix
Copy link

eafelix commented Feb 25, 2015

Genial, copado que nos alineamos

@italoacasas
Copy link

guys please, luego hagan un resume como va a hacer

On Wed, Feb 25, 2015 at 9:34 AM eafelix [email protected] wrote:

Genial, copado que nos alineamos


Reply to this email directly or view it on GitHub
https://github.com/iojs/iojs-es/issues/73#issuecomment-75969402.

@ipeluffo
Copy link

A modo de aclaración, lo que propone @a0viedo no es PR desde Transifex sino desde la organización www.github.com/iojs-es (al menos eso es lo que entendí)

En el issue #38 se intentó clarificar cómo sería un buen workflow pero creo que la discusión no tuvo seguimiento por todos.
Incluso en uno de los mensajes escribí un draft de cómo entendía que era el workflow hasta ese momento (ver comentario) con el fin de clarificarlo y pasarlo en limpio.

IMHO usar el README para llevar un seguimiento de qué partes están siendo traducidas y por quien no es un buen uso del mismo. Para eso creo que están los issues usados de manera particular como propuse o como se comenzó haciendo en este issue, las dos alternativas son válidas y lo mío fue una propuesta solamente.

@a0viedo
Copy link
Member

a0viedo commented Feb 25, 2015

ok yo imagino que sería de la siguiente forma: un issue con la lista de módulos y checkboxes, con las personas asignadas a la traducción y lo tildaríamos cuando esté mergeado el PR. adicionalmente podría abrirse un issue por módulo, cómo hizo @SametSisartenep, y referenciarlo en la lista de los módulos.

@stringparser
Copy link

Me he apuntado a 3 secciones

  • Assertion testing
  • Buffer
  • Readline

cuando tenga algo abro el issue

@sergiolepore sergiolepore mentioned this issue Feb 26, 2015
@SametSisartenep
Copy link
Author

¿Le ha afectado a alguien el salto de la versión v1.3.0 a la v1.4.1, con respecto a la documentación?

@stringparser
Copy link

Yo no he empezado aún, lo haré hoy. @SametSisartenep a ti te ha afectado?

@SametSisartenep
Copy link
Author

@stringparser No, en mi parte no ha cambiado nada. Leí que hubo cambios en la API interna de streams, pero no afecta a los ejemplos de la documentación :) .
Llevo alrededor del 60% (según mi indicador de Vim :P ), y espero terminar la sección antes del miércoles.

@stringparser
Copy link

@SametSisartenep haha, perfect. Pues a ver si yo también tengo lo mío para el miércoles ;)

@eafelix
Copy link

eafelix commented Mar 2, 2015

Menos mal, yo ahora estaba por ponerme con streams , no estaba al tanto del cambio, gracias por checkearlo

This was referenced Mar 3, 2015
@stringparser
Copy link

Pasado al GT - Documentación en #94

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

8 participants