El 02/11/14 a las 19:52, Benoît Minisini escribió: > Le 02/11/2014 18:46, Jesus a écrit : >>> >>> No, the problem is that I can't know if the new translations can be >>> merged directly or not. >>> >>> Because some of the translations can be part of a backportable bug fix, >>> and some others can be part of a new development feature that cannot be >>> backported. And translations files does not like to be merged... >>> >>> So the translation merge must be done manually with the IDE by taking >>> the translations files from the /trunk and import them in the >>> /branches/3.X. It's a big job if I have to do that for the IDE, all the >>> components projects, all the examples... >>> >>> I need a solution to automate that... >>> >> >> Do you mean I could do it by updating 3.6 branch while maintaining trunk >> apart with its new features? In other words, does it worth doing an >> import of lang files only for the 3.6 branch? Or directly on 3.6.1? > > Everything is done on '/trunk' and '/branches/3.X'. Nothing is done > elsewhere, except for fixing a mistake before a version release that is > based on '/tags/3.X.Y'.
So, to be clear, should I update /branches/3.6? That way we could have an updated and complete Spanish translation into the upcoming 3.6.2, right? > >> >> If I could update 3.6.1, probably we have a chance to get Spanish >> language updated in Sebikul's Beta PPA, but obviously, I need a clear >> statement about what to do then. >> >> It seems like branching overcomplicates language maintenance in this >> very specific case. >> >> Regards >> > > The IDE can merge a translation file into a project. I.e., it takes all > non-existing translations, and check if it can find one in the imported > translation file. > > I "just" need to allow this feature from the command-line, so that I can > write a script that merge all translations files of '/trunk' into > '/branches/3.X'. I also need to implement an option to tell that the > translation in the imported file must override the translation in the > project. > > Quite a job again. :-) > In the meantime, I guess we could continue doing this "manually". That's not a problem for me. Regards -- Jesus Guardon ------------------------------------------------------------------------------ _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
