Thanks a lot for sharing your procedure. In our case, since our project is smaller I think we can simplify it a bit. After reading the docs, it seems to me that an update from VCS maintains all the already translated strings, because it does a merge at string level. So, even if the translations are not committed, they will not be lost (if I understand well). So my plan is basically to run a daily update_from_vcs from cron. And the translator themselves can commit their work to vcs, or I could do it if they forget to do it.
But I am facing a problem with the "update_from_vcs" command. If I click on the link "Update from VCS" for a given file, the last version of the file is pulled from SVN, and Pootle is updated with all the strings coming from SVN. However, if I try to accomplish the same through a command line by running "python manage.py update_from_vcs" it doesn't work. After the command, the corresponding file in /repos/myproject/... is not updated to the last SVN version, so it seems to me that something is not working in the "update_from_vcs" command. These are the logs when running it with --verbosity=3: 2013-02-11 10:10:58,752 DEBUG Merging /pt_BR/trabber/HotelMessages.properties 2013-02-11 10:10:58,764 DEBUG cache miss for /pt_BR/trabber/Messages.properties:get_mtime 2013-02-11 10:10:58,768 DEBUG Cache miss for /srv/ translate.trabber.com/pootle/pootle/po/trabber/pt_BR/Messages.properties 2013-02-11 10:10:58,860 DEBUG Cache miss for /srv/ translate.trabber.com/pootle/pootle/po/trabber/pt_BR/Messages.properties 2013-02-11 10:10:58,861 DEBUG Parsing version control copy of trabber/pt_BR/Messages.properties into db 2013-02-11 10:10:58,861 DEBUG Updating /pt_BR/trabber/Messages.properties 2013-02-11 10:10:58,879 DEBUG cache miss for /pt_BR/trabber/Messages.properties:getquickstats 2013-02-11 10:10:59,059 DEBUG Merging trabber/pt_BR/Messages.properties with version control update 2013-02-11 10:10:59,059 DEBUG Merging /pt_BR/trabber/Messages.properties 2013-02-11 10:10:59,087 DEBUG cache miss for /pt_BR/trabber/:getquickstats Any idea about why is not working? Which are the differences between the "Update from VCS" link and the "update_from_vcs" command? Should I do something (like updating the svn checked out files) before executing "update_from_vcs" ? Thanks! Óscar On Sat, Feb 9, 2013 at 4:39 PM, Chris Leonard <cjlhomeaddr...@gmail.com>wrote: > On Fri, Feb 8, 2013 at 2:47 PM, Óscar Frías Barranco <ofr...@gmail.com> > wrote: > > I would like to use VCS as the reference and most up to date version of > the > > translation files. > > I'm not sure exactly how that would work as the input occurs via > Pootle, so of necessity (at least momentarily) Pootle will have a more > completed PO file than the repo. > > > And I would like Pootle to always have the same content that is in VCS. > > I completely agree that keeping Pootle and the repo /po directory as > synched up as possible is desirable; but the natural dataflow is from > Pootle to the repo (at least for the PO files). > > > For that I think I need two things: > > 1) have a way to update Pootle from VCS from a cron job. I think this > full > > update from VCS would require first to do an update from VCS for every > > file, and then "Update against templates" for every language. > > 2) every translator must commit to VCS his work every time > > > > Does this make sense? > > Point 2 requires that every translator be a language admin (with > commit priv). That fails to take advantage of the features of Pootle > as a collection point and staging area for draft translations that can > be reviewed prior to commit to the repo (e.g. suggestions, > submissions, pofilter checks, etc.). I'm not brave enough to take > that step, and with 130 languages, the reality is that at any given > time, I may not have a suitable lang admin for some languages. > > > The second bullet is a matter of discipline, but do you know how to do > > number 1 from command line ? > > No question that certain disciplines must be observed and that cron > jobs are a very useful tool for doing the synch between Pootle and the > repo. > > Let me describe the Sugar Labs workflow, which is different then that > you propose, but I will describe why we do it this way. Even if you > are not convinced by my arguments (and you need not be), some of the > scripts I will point you to may be of use to you. > > 1) Developers add i18n to their code and generate the first POT file, > placing it in the /po directory. After that the discipline we ask for > is that they never touch the /po directory directly again. It is a > discipline of restraint from taking an action, so it is easier to get > compliance than a discipline of needing to take an action (as you > pprpose for translators). > > 2) Developers must add the special gituser: "pootle" as a committer to > the repo. The SSH key for this proxy user was created by the Pootle > and repo admins, and this user acts as a go between between Pootle > users and the repo. No repo commit privs are needed for individual > translators or even lang admins. > > 3) Pootle admins take care of adding new repos to Pootle, typically > when a developer files a ticket requesting L10n. > > http://wiki.sugarlabs.org/go/Service/translate > > 4) The Pootle server has a local git copy of the repo. Cron jobs keep > it synched up on a nightly basis. We keep copies of these scripts in > our repo at: > > http://git.sugarlabs.org/pootle-helpers/mainline > > in particular the potgenerator script is key. > > 5) A nightly cron job regenerates the POT (with any fresh changes from > the repo) and sends an e-mail that lets me know if any changes have > been made that would require an "Update from Templates". > > 6) Pootle users themselves can do an "Update from Templates" if they > want to be sure they have the latest files to work on, I typically do > a bulk update as a maintenance step if it seems needed. > > 7a) Only lang admins have "commit to VCS", the essentially borrow the > gituser: pootle commit priv, but are de facto only able to commit PO > files, limiting the harm that can be done. Only lang admins are given > "upload with overwrite" priv. > > 7b) Registered and logged on users pick up the "default" user privs > and can "submit" translations. They can upload, but not with over > write. > > 7c) Drive-by (unregistered or not logged in) users can only make > suggestions by picking up the "nobody" user privs, Of course, they > can download for off-line work. > > 8) Pending translations to be committed can be seen by the Pootle > admins by doing a "git status" on the repos on the Pootle server. > > I know this is not the workflow you are describing at all, but this > does keep developers focused on developing and translators focused on > translating and minimizes th echance of them interfering with each > other while providing a means for them to stay as synched up as > feasible. Essentially L10n is a service that developers can "sign up > for". > > It has worked for us for years with a broad diversity of independent > developers releasing at different times and a large translation > community. YMMV. > > cjl > Sugar Labs Translation Team Coordinator > ------------------------------------------------------------------------------ Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb _______________________________________________ Translate-pootle mailing list Translate-pootle@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/translate-pootle
