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). 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 > >
