On 9/6/13 6:33 PM, janI 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).
good > > 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 ? I don't really get your point, if a developer/translator don't care about what he is doing the risk that he damage something is always very high. If I am interested in language builds I check out trunk which includes main and extras. So I am safe an I know what I am doing and expect that other developers know what they are doing as well. Translators probably never build on their own and use nightly builds from the build bots. The build env ensures that trunk or whatever common root (branch or tag) is updated correctly before the build starts. I see no real problem here. > > 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 ? the code necessary for certain platforms is integrated all over and it is far to complicate to extract this. Possible but I see no advantage here at this time. The handling with ignore file is far more error prone to me ... > > 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 don't think so, en-US was chosen as the development language and it is part of the source directly. It's not only src files but en-US strings are also config files, help files, property files etc. I don't see why your proposed workflow should not work with having the po files in a separate directory whatever the name would be. I see consensus on the general workflow and the only point where we disagree is the location of the po files. A still minor detail from my point of view but anyway. Juergen > 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). > > 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
