On Fri, Sep 6, 2013 at 12:33 PM, janI <j...@apache.org> wrote: > On 6 September 2013 16:53, Dick Groskamp <th.grosk...@quicknet.nl> wrote: > >> Op 6-9-2013 14:30, janI schreef: >> >> Hi >>> >>> I am copying this mail to the l10n list, in order to involve the >>> translators that do not follow dev@. But lets please keep the discussion >>> on >>> dev@. >>> >>> As its hopefully known, I have been working on a new workflow for the >>> whole >>> translation process for quite a long time. >>> >>> Now I have released the first major part of the workflow, my ultimate >>> commit has lead to some valid concerns from Jürgen and Herbert, this is >>> the >>> second time (during development) that I hear the essentially same concern. >>> >>> Therefore we a a community need to decide which road we want to follow. >>> >>> The workflow I am developing, would in the final phase look like (without >>> technical details). >>> >>> 1) at regular intervals en-US text are extracted from our source tree, >>> transferred to pootle as templates, and all languages are updates with >>> new/changed/deleted keys. This part is partly manual (starting the build, >>> updating the languages). >>> >>> 2) Translators work on pootle, Translator-comitters update languages in >>> svn >>> from pootle and start an offline language-pack build. >>> >>> 3) Translators test their translation using the binary from our buildbot >>> + >>> language pack (translators debug tool). Turnaround time < 1 day. >>> >>> 4) Buildbot automatically include changed translations on regular builds >>> (e.g. weekly). >>> >>> The 2 concerns that have been raised are: >>> 1) Letting committers do "svn commit" and "svn up" directly in pootle, >>> might produce a build breaker for our buildbots. Suggestion let an admin >>> do >>> it e.g. once a week. >>> >>> my opinion: We do not need an admin in the loop, we dont have a >>> controlling >>> for developers and they are even more likely to produce build breakers. >>> Remember a .po file build breaker will only affect the language in >>> question >>> and can be repaired just as fast. >>> >>> 2) Containing the .po files (translations) inside main/ cost 600Mb extra >>> for en-US developers to download. Suggestion keep the .po file away from >>> main in extras. >>> >>> my opion: Translator work is NOT "extra", its an essential needed part for >>> our builds. In contrast to e.g. cliparts, the .po are part of the setup >>> package (of course transformed, similar to a C++ source). >>> >>> My workflow can work, not as efficient with 1), but 2) breaks the workflow >>> for technical reasons (think of someone extracting en-US strings from an >>> updated /main to an old /extra and the published it to pootle == LOT of >>> extra translation in all languages. >>> >>> I see translators working at the same level as developers, not as >>> something >>> /extras, and therefore the work should be treated as such. >>> >>> I have stopped work on further integration of genLang, until I either get >>> lazy consensus on my workflow, or we decide to go for another workflow. >>> >>> thanks in advance for your comments (please all on dev@). >>> >>> rgds >>> jan I. >>> >>> In general I have no problem with this workflow and think >> it might speed up things for the builders side of the proces. >> >> The only problem I have is that I'm no techie and SVN is, to be honest, >> to complicated for me. >> >> Would it be possible, for instance after the deadline for translation has >> passed, >> for a builder/developer/admin to update ALL languages from POOTLE? >> >> I think with something like that we would have have ALL alterations into >> SVN >> at once. >> Mind you I have no idea how much work that would be, but it seems >> to me it gives some assurance about the imported strings. >> >> -- >> DiGro >> ___________________________ >> Apache OpenOffice 4.0.0 (Dutch) and scanned with Ziggo extended security >> (F-Secure) >> >> thanks for all the comments so far, I am real impressed. > > I have to correct/clarify a couple of things. > > 1) the build process will not and should not do "svn commit", that are done > by manually by developers and translator-committers when they feel their > part is ready (just as developers do). > > 2) The emotional part of being in /main or /extra is very important, and > one I fight for. But equally important it that my workflow will not work > safely, if it works with 2 svn trees. The chances that someone does a build > in /main with an not updated /extra (because he/she dont care) is too high, > and the consequences are down right frightening. If it happes, it might > change the translation templates, which again changes all language files, > which ultimately calls for translators to translate false texts. Is that > really wanted ? > > 3) There are absolutely no need to separate at svn/git level, but systems > have a .ignore facility so directory can be ignored and left empty (which > would be no problem for my workflow) so any developer not wanting the full > package, can still do a "svn co main" and limit to what is wanted. Btw I > dont need MAC development, why do I have to dowload that ? > > 4) When we walk about making the system modular, and want to separate e.g. > connectivity.po from /main/connectivity, we could use the same argument to > move all .src files away from main, in both cases we cannot generate a full > AOO installation. Actually modern modularity would call for the .src files > (and others) to contain the KID code, so that en-US could be translated as > well. We assume that our developers speak perfect en-US, which I think is > far from the case (remember the ripples when a developer changes the en-US > strings, ALL languages have to be updated). > > I will of course wait the 72 hours, but it seems to me that there are no > real consensus about integrating my proposed workflow (which NEEDS > integrated po files). >
It has only been 5 hours. Let's wait for at least 10% of 72 hours to pass before drawing conclusions ;-) -Rob > rgds > jan i. > > > >> >> >> ------------------------------**------------------------------**--------- >> To unsubscribe, e-mail: >> dev-unsubscribe@openoffice.**apache.org<dev-unsubscr...@openoffice.apache.org> >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
