Idiomas
10 views
Skip to first unread message
JuanCri
Nov 14, 2008, 3:11:22 PM11/14/08
to Factura Sharp Desarrollo
Uno de los dilemas que tuve que enfrentar al crear el proyecto en
Google Code fue "¿En qué idioma lo escribo?". Debido a que quienes
contribuyen al proyecto son miembros de Mono Hispano, decidí crear
esta lista en español, aunque en algún momento podría ser necesario
crear una lista en inglés cuando exista demanda para que eso ocurra.
En el lado del código, creo que lo mejor sería utilizar inglés tanto
para los objetos de programación como para los comentarios. Así, la
clase de boleta probablemente deba llamar Invoice y no Boleta ni
Factura.
¿Qué creen ustedes? ¿Será esto un problema para que programadores de
habla hispana se sumen al proyecto? Espero que no.
Atte,
Juan Cristóbal Olivares
Google Code fue "¿En qué idioma lo escribo?". Debido a que quienes
contribuyen al proyecto son miembros de Mono Hispano, decidí crear
esta lista en español, aunque en algún momento podría ser necesario
crear una lista en inglés cuando exista demanda para que eso ocurra.
En el lado del código, creo que lo mejor sería utilizar inglés tanto
para los objetos de programación como para los comentarios. Así, la
clase de boleta probablemente deba llamar Invoice y no Boleta ni
Factura.
¿Qué creen ustedes? ¿Será esto un problema para que programadores de
habla hispana se sumen al proyecto? Espero que no.
Atte,
Juan Cristóbal Olivares
Martin Trejo
Nov 14, 2008, 3:24:07 PM11/14/08
to factura-shar...@googlegroups.com
Para bien o para mal el inglés es el idioma común dentro del desarrollo. A mi parecer no hay vuelta de hoja. Lo que si se debe considerar es la creación de documentación en español y que los comentarios dentro del código también sean en español.
Saludos,
Gabriel Acevedo H.
Nov 14, 2008, 3:38:19 PM11/14/08
to factura-shar...@googlegroups.com
Estoy en desacuerdo con Martín. Creo que lo más importante es que los
comentarios del código sean en Inglés. De esta forma, podríamos
recibir ayuda de programadores de cualquier parte del mundo.
¡Saludos!
2008/11/14 Martin Trejo <chilli...@gmail.com>:
--
-------------------------------------------
G a b r i e l A c e v e d o H i d a l g o
comentarios del código sean en Inglés. De esta forma, podríamos
recibir ayuda de programadores de cualquier parte del mundo.
¡Saludos!
2008/11/14 Martin Trejo <chilli...@gmail.com>:
-------------------------------------------
G a b r i e l A c e v e d o H i d a l g o
Alberto León
Nov 14, 2008, 3:50:29 PM11/14/08
to factura-shar...@googlegroups.com
Inglés, sin más.
René Trejo
Nov 14, 2008, 4:04:41 PM11/14/08
to factura-shar...@googlegroups.com
Deberiamos analizar lo siguiente el proyecto en un inicio se esta pensando para ser lanzado a nivel latinoamerica, para lo cual seria bueno tomar en cuenta lo siguiente:
Los sistemas tributarios de los diferentes paises de habla hispana por medio de publicaciones le dan a conocer al publico la tecnologia que sera utilizada para la emisión de facturas electronicas, en un caso particular y que he trabajado es en México y aca el sistema tributario proporciona esquemas que son lo encargados de establecer la estructura que deberá tener el archivo de factura electrónica que en este caso es un archivo xml.
Veamos el problema que seria tener una clase llamada Invoice y en nuestra estructura de archivo de factura nos pide un nodo con nombre Comprobante, seria un revoltura de idioma por eso creo que no se debe de tomar tan a la ligera el idioma y verificar el comportamiento de los diferenetes esquemas a nivel latinoamerica. En México la estructura de clases que tuve que generar para la emisión de facturas esta completamente en español para evitar este tipo de revoltura de idioma.
René Trejo
Los sistemas tributarios de los diferentes paises de habla hispana por medio de publicaciones le dan a conocer al publico la tecnologia que sera utilizada para la emisión de facturas electronicas, en un caso particular y que he trabajado es en México y aca el sistema tributario proporciona esquemas que son lo encargados de establecer la estructura que deberá tener el archivo de factura electrónica que en este caso es un archivo xml.
Veamos el problema que seria tener una clase llamada Invoice y en nuestra estructura de archivo de factura nos pide un nodo con nombre Comprobante, seria un revoltura de idioma por eso creo que no se debe de tomar tan a la ligera el idioma y verificar el comportamiento de los diferenetes esquemas a nivel latinoamerica. En México la estructura de clases que tuve que generar para la emisión de facturas esta completamente en español para evitar este tipo de revoltura de idioma.
René Trejo
JuanCri
Nov 16, 2008, 11:58:40 AM11/16/08
to Factura Sharp Desarrollo
Creo que deberíamos separar los conceptos. Si bien crear el esquema de
objetos basados en los nombres de las etiquetas XML de los documentos
puede ser útil para un programa particular (que se ajusta a una
regulación en particular), tenemos que hacerlo diferente para este
tipo de aplicaciones que tendrán implementaciones locales.
Hay dos opciones:
1.- Se crea una clase que escribe y lee los archivos XML para una
implementación en particular (México, Chile, Argentina, España, Perú,
etc, etc). [usando XmlReader y XmlWriter]
2.- Se crean objetos propios para cada implementación (país) y esos se
pueden castear fácilmente a las clases de la aplicación principal
[usando serialización xml]
En ambos casos, necesitamos crear clases que se compartan entre todas
las implementaciones. Creo que lo más sabio sería tener estas clases
en inglés. De lo contario, estaríamos limitando demasiado el proyecto
y restringiendo colaboración valiosa del resto de los programadores
que no saben español.
Los comentarios también deberían estar en inglés, si seguimos este
patrón. Tal vez las extensiones locales puedan tener comentarios en el
idioma del país para el cual se desarrollan. De todas maneras, este
grupo de discusión está hecho en español y así seguirá siendo, aunque
en algún momento se cree uno en inglés, el cual sería paralelo.
Atte,
Juan Cristóbal Olivares
On Nov 14, 6:04 pm, "René Trejo" <rene.tr...@gmail.com> wrote:
> Deberiamos analizar lo siguiente el proyecto en un inicio se esta pensando
> para ser lanzado a nivel latinoamerica, para lo cual seria bueno tomar en
> cuenta lo siguiente:
>
> Los sistemas tributarios de los diferentes paises de habla hispana por med de publicaciones le dan a conocer al publico la tecnologia que sera
objetos basados en los nombres de las etiquetas XML de los documentos
puede ser útil para un programa particular (que se ajusta a una
regulación en particular), tenemos que hacerlo diferente para este
tipo de aplicaciones que tendrán implementaciones locales.
Hay dos opciones:
1.- Se crea una clase que escribe y lee los archivos XML para una
implementación en particular (México, Chile, Argentina, España, Perú,
etc, etc). [usando XmlReader y XmlWriter]
2.- Se crean objetos propios para cada implementación (país) y esos se
pueden castear fácilmente a las clases de la aplicación principal
[usando serialización xml]
En ambos casos, necesitamos crear clases que se compartan entre todas
las implementaciones. Creo que lo más sabio sería tener estas clases
en inglés. De lo contario, estaríamos limitando demasiado el proyecto
y restringiendo colaboración valiosa del resto de los programadores
que no saben español.
Los comentarios también deberían estar en inglés, si seguimos este
patrón. Tal vez las extensiones locales puedan tener comentarios en el
idioma del país para el cual se desarrollan. De todas maneras, este
grupo de discusión está hecho en español y así seguirá siendo, aunque
en algún momento se cree uno en inglés, el cual sería paralelo.
Atte,
Juan Cristóbal Olivares
On Nov 14, 6:04 pm, "René Trejo" <rene.tr...@gmail.com> wrote:
> Deberiamos analizar lo siguiente el proyecto en un inicio se esta pensando
> para ser lanzado a nivel latinoamerica, para lo cual seria bueno tomar en
> cuenta lo siguiente:
>
> utilizada para la emisión de facturas electronicas, en un caso particular y
> que he trabajado es en México y aca el sistema tributario proporciona
> esquemas que son lo encargados de establecer la estructura que deberá tener
> el archivo de factura electrónica que en este caso es un archivo xml.
>
> Veamos el problema que seria tener una clase llamada Invoice y en nuestra
> estructura de archivo de factura nos pide un nodo con nombre Comprobante,
> seria un revoltura de idioma por eso creo que no se debe de tomar tan a la
> ligera el idioma y verificar el comportamiento de los diferenetes esquemas a
> nivel latinoamerica. En México la estructura de clases que tuve que generar
> para la emisión de facturas esta completamente en español para evitar este
> tipo de revoltura de idioma.
>
> René Trejo
> El 14 de noviembre de 2008 14:38, Gabriel Acevedo H.
> <gacev...@gmail.com>escribió:
> que he trabajado es en México y aca el sistema tributario proporciona
> esquemas que son lo encargados de establecer la estructura que deberá tener
> el archivo de factura electrónica que en este caso es un archivo xml.
>
> Veamos el problema que seria tener una clase llamada Invoice y en nuestra
> estructura de archivo de factura nos pide un nodo con nombre Comprobante,
> seria un revoltura de idioma por eso creo que no se debe de tomar tan a la
> ligera el idioma y verificar el comportamiento de los diferenetes esquemas a
> nivel latinoamerica. En México la estructura de clases que tuve que generar
> para la emisión de facturas esta completamente en español para evitar este
> tipo de revoltura de idioma.
>
> René Trejo
> El 14 de noviembre de 2008 14:38, Gabriel Acevedo H.
>
>
>
> > Estoy en desacuerdo con Martín. Creo que lo más importante es que los
> > comentarios del código sean en Inglés. De esta forma, podríamos
> > recibir ayuda de programadores de cualquier parte del mundo.
>
> > ¡Saludos!
>
> > 2008/11/14 Martin Trejo <chilli.co...@gmail.com>:
>
>
> > Estoy en desacuerdo con Martín. Creo que lo más importante es que los
> > comentarios del código sean en Inglés. De esta forma, podríamos
> > recibir ayuda de programadores de cualquier parte del mundo.
>
> > ¡Saludos!
>
> > > Para bien o para mal el inglés es el idioma común dentro del desarrollo.
> > A
> > > mi parecer no hay vuelta de hoja. Lo que si se debe considerar es la
> > > creación de documentación en español y que los comentarios dentro del
> > código
> > > también sean en español.
> > > Saludos,
> > > Martín Trejo Chávez
>
> > > 2008/11/14 JuanCri <juan...@gmail.com>
> > A
> > > mi parecer no hay vuelta de hoja. Lo que si se debe considerar es la
> > > creación de documentación en español y que los comentarios dentro del
> > código
> > > también sean en español.
> > > Saludos,
> > > Martín Trejo Chávez
>
Sergio Alva
Nov 18, 2008, 11:00:41 AM11/18/08
to Factura Sharp Desarrollo
Me parece bien el uso del lenguaje ingles para código y comentarios,
pero el comentario de René es muy cierto, no se debe de tomar a la
ligera la probable mezcla de lenguajes por el hecho de que cada país
maneja sus procesos conceptuales de manera diferente, puede
convertirse en algo dificil de manejar a largo plazo.
Hay que establecer una especificación bastante clara pero no tiene por
que se complicada. Tambien estoy de acuerdo que las interfaces o
clases (dependiendo lo que como se establezca) base, deben estar
escritas en ingles.
Saludos.
pero el comentario de René es muy cierto, no se debe de tomar a la
ligera la probable mezcla de lenguajes por el hecho de que cada país
maneja sus procesos conceptuales de manera diferente, puede
convertirse en algo dificil de manejar a largo plazo.
Hay que establecer una especificación bastante clara pero no tiene por
que se complicada. Tambien estoy de acuerdo que las interfaces o
clases (dependiendo lo que como se establezca) base, deben estar
escritas en ingles.
Saludos.
JuanCri
Nov 24, 2008, 7:08:35 AM11/24/08
to Factura Sharp Desarrollo
Aunque los procesos en cada país son distintos, hay algunas reglas en
común que se pueden tomar en cuenta al crear el código. Por ejemplo,
si tenemos una clase Invoice, ésta debe tener items. A su vez, estos
ítems pueden especificar impuestos, que en nuestro caso sería Taxes.
La misma clase Invoice podría guardar otros impuestos adicionales en
su propiedad Taxes, que debería ser algo como un diccionario. Además,
para soportar múltiples monedas, se puede tener una estructura (sea
clase, código, etc) que especifique el tipo de moneda.
La manera de trabajo que se me ocurre es que se habra un hilo de
discusión por cada ítem (por ejemplo: factura, boleta, nota de
crédito, nota de débito, etc). En este hilo, las personas de distintos
países nos dirán qué necesitan para que este ítem funcione con su
legislación. Una vez que hemos establecido las similitudes, una
personas será la encargada de juntar todo esto y llevarlo a código.
Otra forma de trabajar sería que simplemente creáramos las clases lo
más básico posible y luego, pequeños grupos de trabajo de cada país
pueden aportar parches para que el código funcione bajo su regulación.
Esto es abierto y tal vez necesitamos un hilo nuevo para esto. ¿Se les
ocurren otras ideas?
Atte,
Juan Cristóbal Olivares
común que se pueden tomar en cuenta al crear el código. Por ejemplo,
si tenemos una clase Invoice, ésta debe tener items. A su vez, estos
ítems pueden especificar impuestos, que en nuestro caso sería Taxes.
La misma clase Invoice podría guardar otros impuestos adicionales en
su propiedad Taxes, que debería ser algo como un diccionario. Además,
para soportar múltiples monedas, se puede tener una estructura (sea
clase, código, etc) que especifique el tipo de moneda.
La manera de trabajo que se me ocurre es que se habra un hilo de
discusión por cada ítem (por ejemplo: factura, boleta, nota de
crédito, nota de débito, etc). En este hilo, las personas de distintos
países nos dirán qué necesitan para que este ítem funcione con su
legislación. Una vez que hemos establecido las similitudes, una
personas será la encargada de juntar todo esto y llevarlo a código.
Otra forma de trabajar sería que simplemente creáramos las clases lo
más básico posible y luego, pequeños grupos de trabajo de cada país
pueden aportar parches para que el código funcione bajo su regulación.
Esto es abierto y tal vez necesitamos un hilo nuevo para esto. ¿Se les
ocurren otras ideas?
Atte,
Juan Cristóbal Olivares
Reply all
Reply to author
Forward
0 new messages