Karl Eichwalder napisał(a):
If you copy files from and to the Novell repository, it takes time. I'd like to see us improving the Novell repository in a way that private repositories become superfluous.
Let me briefly describe the situation we deal with and the ways we've been trying to solve the problems. Out of about 10 to 15 people in out team, only 2 have the write access to Novell Forge repository. This is reasonable, of course, since 2 seems like enough. We make use of our private repository (also managed with svn), located on our server aviary.pl. This one is open for write access to every translator in our team. To facilitate synchronising the two repositories, I've started to write very simple Bash scripts, which automate the process. One of them is called nvl-sync, and it takes one obligatory argument (aviary or forge) and one optional one (--no-merge) 1) ./nvl-sync forge This command is used to transfer the files from our private repo to yours. It is issued in the working copy of Novell Forge repository. It exports the files from aviary.pl repo, and copies them over the files in the local copy. It is issued only by either of the two persons with the write access to Novell Forge - otherwise it makes little sense ;-) 2) ./nvl-sync aviary This command is issued to transfer the files from Novell Forge to the Aviary.pl repository. We encourage translators to issue it every time they start working - this way we ensure, that they're working with the newest version of translation catalogues. It works by exporting pot files form Forge repository, po files from the ours, merging them and copying them over the files currently located in local copy of Aviary.pl repository. We merge files instead of just getting po's from your server, because that was the easiest way we could make commits to our repo safe. Consider this scenario: a) a translator gets the newest po's from the Forge, they translate a few strings and commit the changes to our repo. b) an other translator gets the newest po's from the Forge (the very same as in A), they translate a few strings and commit their changes to our repo *overwriting* the files changes by the first translator. c) a person with write access to the Forge synchronises the repositories As you can see, one of the solutions would be to synchronise repositories right after every single commit to our repository, which is obviously impossible. The other is to merge pot files (newest strings) with our po files (newest translations). 3. ./nvl-sync aviary --no-merge This command is reserved for special occasions, like the merge rounds you sometimes run. It gets po files from the Forge and copies them over to our repo. This is very useful, since this way we are able to use your translation memory tools, and we transfer better po files over to our repo (more exact matches, better fuzzy matches). BTW. could you point me to some recommendable resources about translation memory technologies? Currently we use a few compendia files merged from files we'd beed working on during the localisation of Now, for a totally different kettle of fish: Have you considered migrating form SVN to a distributed version control system? I am aware that your svn server itself is rather a new addition to the localisation process, but maybe you could give tools like darcs and bzr a thought? I read also about DVCS called svk, which started as an SVN wrap-around, and now has developed into something more mature. Not sure how well it works, tough, I don't have any experience with it.
Maybe, adding pootle to our site would be a win. That's something to be evaluated after 10.2 (see https://bugzilla.novell.com/show_bug.cgi?id=208982 )
This definitely sounds like a good idea. Especially if you want to lower the barriers to entry for the community. We spent considerable amount of time explaining newcomers how to use svn and KBabel or poEdit. And I'm still willing to do that of course, although pootle seems incredibly appealing :-)
In the past we agreed that "approx. 10%" is allowed for the 2nd round. I'd like to avoid additional bugzilla mails. Maybe, it is already possible to filter the opensuse bugmails somehow.
Fot the time being, your annoucments on the list are very helpful. I've also written a small script to easily display changes made to pot files each time I do svn up. BTW. What is the definitive deadline for submitting the translations so that they land in openSUSE 10.2? We have some new strings in yast2-apparmor and html-help-install that need to be taken care of. Best regards, Stanisław Małolepszy -- aviary.pl l10n team http://aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org