On Fri, Sep 6, 2013 at 8:30 AM, janI <j...@apache.org> wrote: > 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). >
I'd plan for growth here. I see no reason why we will not end up with 100+ languages in the future. Certainly there were that many with OpenOffice.org. So if we have 600Mb for 25 or so languages, will it still be a reasonable layout when the languages take up 2.4 GB? -Rob > 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. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
