Inicio > Mis eListas > nave > Mensajes

 Índice de Mensajes 
 Mensajes 2801 al 2820 
AsuntoAutor
Re: Algo curioso Bernardo
Re: MozEs Bernardo
Re: Ya está el ins Oscar Ma
sobre los problema Bernardo
Re: Ya está el ins Víctor F
Re: Algo curioso Bernardo
Re: NAVE en la lis Bernardo
Re: sobre los prob Oscar Ma
Re: NAVE en la lis Antonio
Re: NAVE en la lis Bernardo
Enlace a las relea Bernardo
Re: Enlace a las r Oscar Ma
Re: Enlace a las r Bernardo
Re: Enlace a las r Oscar Ma
Re: Anuncio: 1.4 d Oscar Ma
Re: Anuncio: 1.4 d Oscar Ma
Re: Algo curioso Ricardo
Re: MozEs Ricardo
Re: NAVE en la lis Ricardo
Re: Anuncio: 1.4 d Ricardo
 << 20 ant. | 20 sig. >>
 
Proyecto NAVE
Página principal    Mensajes | Enviar Mensaje | Ficheros | Datos | Encuestas | Eventos | Mis Preferencias

Mostrando mensaje 2835     < Anterior | Siguiente >
Responder a este mensaje
Asunto:Re: [nave] NAVE en la lista de proyectos de traducción de Mozilla Firebird
Fecha:Viernes, 4 de Julio, 2003  02:19:07 (+0200)
Autor:Ricardo Palomares Martinez <rpm @.......es>
En respuesta a:Mensaje 2823 (escrito por Bernardo Arlandis Mañó)

Bernardo Arlandis Mañó escribió: 
> Ricardo Palomares Martinez escribió: 
>  
>> Con todo, seguimos teniendo un punto borroso en esta disgregación de 
>> productos, y es si en el futuro Mozilla Firebird seguirá manteniendo 
>> un camino independiente de Mozilla Suite 1.5 y superior o, por el 
>> contrario, pasará a ser uno de los dos componentes principales de la 
>> Suite. Aunque instalable independientemente, su desarrollo iría en 
>> este caso sincronizado a Mozilla Thunderbird para el lanzamiento de 
>> las sucesivas versiones de la Suite. 
>> 
> No entiendo donde está la confusión. Mozilla Suite será firebird y 
> thunderbird, lo que está un poco incierto es si composer y chatzilla se 
> incluirán como parte de la suite y si pasarán a ser extensiones. 
 
 
Aparentemente, Mozilla Suite será Mozilla Firebird + Mozilla 
Thunderbird + el resto de componentes que hasta ahora forman la suite 
(y quizá alguno más que sea de uso común) [1]. El número exacto de 
piezas no es el problema. 
 
Mozilla Firebird y Mozilla Thunderbird van a ser productos instalables 
de manera independiente, para así no forzar a tener instalado un 
programa de correo a quien no quiere usar Mozilla Mail sino sólo 
Mozilla Navigator, y viceversa. Al mismo tiempo, la integración entre 
ambos programas estará lo más cuidada posible para mantener la suite 
como un producto de calidad. Tampoco esa dualidad individuos + equipo 
es el problema. 
 
El problema está, desde mi punto de vista, en que hay varias maneras 
de gestionar los recursos traducibles. Lo más lógico _parece_ que 
sería mantener un Glossary.zip separado por cada componente, 
incluyendo para esta discusión en el concepto de "componente" tanto 
MozFB y MozTB como los demás componentes de Mozilla que pasan a ser 
extensiones y los add-ons externos. 
 
De hacer esto, tendríamos dos Glossary.zip de cierta entidad, otros 
algo más pequeños, y el resto que queramos de tamaño normalmente 
pequeño. Si MozFB y MozTB se manejan de forma autónoma (es decir, no 
lo traducimos en el seno de NAVE, sino que sólo los recogemos y 
generamos los XPIs cuando sea posible, los instaladores, y lo 
anunciamos en l10n), habrá más riesgo de divergencia en la traducción 
de nuevos términos y definitivamente muchos estaremos cruzados de 
brazos mientras unos pocos andan muy liados (recuerdo que, al menos de 
momento, MozFB no incluye archivos de ayuda, sino que remite a un 
sitio web). Estoy suponiendo en este caso que habrá información clara 
desde mozilla.org sobre cómo reunir los distintos Glossary.zip o XPIs 
para obtener una traducción de la suite completa. 
 
Pero hay otras opciones. En mozilla.org pueden generar los "build" de 
la suite del tirón, así que bien podrían generar una suite con un 
único directorio de instalación y, por tanto, un único directorio 
chrome/. Eso podría complicar bastante la generación de la traducción 
de la suite completa por la reordenación de directorios, duplicidad de 
archivos, fusión de archivos equivalentes en uno, etc. dentro de 
chrome/ (o de los .jar de chrome, para el caso). 
 
Independientemente de lo anterior, si el compromiso de mozilla.org con 
el mantenimiento de la suite es alto, también lo será la necesidad 
para ellos de sincronizar la publicación de nuevas versiones 
compatibles y probadas de, al menos, MozFB y MozTB. Quizá, entonces, 
los proyectos MozFB y MozTB no sean tan independientes en su 
desarrollo, después de todo. En ese caso, podría haber incluso un 
único Glossary.zip que diera lugar a más de un XPI igual que ahora de 
un Glossary.zip salen reges.xpi y langeses.xpi (esto sería en una 
próxima versión de MT, que, como comentó su autor en el grupo l10n, 
será adaptado para la nueva arquitectura de Mozilla). 
 
La idea de fondo es que, aunque hay una opción aparentemente más 
lógica, las dos son posibles (y probablemente haya más alternativas), 
y hasta que salga 1.5alpha no vamos a ver de verdad por dónde van los 
tiros. 
 
Saludos. 
 
 
 
[1] http://www.mozilla.org/roadmap.html 
      sección "application architecture" 
 
"In an attempt to avoid an explosion of unique builds that have to be 
supported by mozilla.org, we will likely ship with all of the popular 
extensions installed but disabled, so that they can be easily turned 
on by those who wish to use them, and uninstalled by those who don't." 
 
--  
Microsoft is not the answer, it's the question. And the answer is no. 
 
 
 
 
_______________________________________________________________________ 
Visita nuestro patrocinador: 
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~ 
                 !!Tu correo gratuito para siempre!!  
            10 megabytes de espacio, agenda de direcciones, 
            garantizado de funcionar siempre con eListas.net 
               y por supuesto con el resto de Internet... 
                          !!En GeoMundos!! 
Haz clic aquí ¡YA! -> http://elistas.net/ml/119/ 
~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~