Jörg Jahnke wrote: > Hi Mathias, > > Mathias Bauer schrieb: > ... >> >> Currently the way how localizations get into OOo is very inefficient. At >> some point in time a "deadline" is reached and a whole bunch of >> localizable content is exported from the source tree and handed over. >> Localizers do their work, send it back and have to wait until Sun >> release engineering has collected it and provided a new build containing >> all the work. If bugs are found, the next round follows. I think we can >> do better. >> >> My idea for a long term goal is that all localization related content >> (help, UI etc.) resides in an own Mercurial repository that localizers >> can check out and directly commit to (if they want). A *simple* build >> process (that does not require to check out the whole OOo source) allows >> them to test their results themselves and immediately correct errors, >> but that would be optional. Of course it should still be possible to >> work as today (send changes to Sun release engineering), comparable to >> the situation of code contributors that either can create an own CWS or >> send in patches. >> >> In a system like this localization even does not need to have a >> deadline. Once a feature is done and documented, it can become >> localized. Whether we want to do that is open for discussion. > > Even with the current L10N process this increased flexibility, that you > seem to have in mind, can IMO be reached, since it would be possible to > import the new and changed strings from every milestone into the Pootle > system used for translation. But a little more automation should be done > in order to reach this goal since doing these imports manually is quite > time consuming. Then translators could continuously work on the translation. > > Getting the translations back into the code still requires a CWS. This > work is, at least at the moment, done by Ivo or Vladimir, and they do it > for all languages, saving the L10N teams a lot of work IMO. Currently > such an L10N CWS is created once per release, which means that > translators get feedback on their work quite late. This frequency could > be increased, and I know that Ivo has spent some work on automating the > processes around creating an L10N CWS in order to create these CWS more > often, but AFAIK there still remains some work to do. > > So, while I think you did draw a valid picture of an L10N build process > above, I think we could improve the situation with far less changes to > the current processes and thus far less work. IMO we should try to > implement the improvements I sketched out above first and then see if we > have to go a step further and perhaps change the processes as you > outlined above.
Sure! Every improvement helps. And if we can think about how we can get rid of all the intermediate steps in the long run, that would be great! If I just look on the matter from an exernal POV, I don't see why localization contributions should be treated differently than others. Code developers either create a CWS or send in a patch. Localization developers currently only have option 2, even if they wanted to use option 1 in case they can cope with it. Moreover, they can not even test their patches in a running build, they have to wait for a build done by Sun Releng - what a difference to code contributions! Having both options would be a worthwile goal for the *future* because it reduces the turnaround times and also the number of necessary turnarounds dramatically. And "the future" is what we are currently discussing. Please don't get me wrong, not everything what I have written means that I want it all and I want it now. :-) Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
