Carlos E. R. skreiv 10. mars 2016 19:20:
access, and fetch and commit translations using SVN. It works extremely well. Translators just have to do a
svn up
to fetch the files, translate them and then do a
svn commit But not against the source tree the devs use, but your own, for
I work as a translator for KDE. There the translators have commit translation, right?
Originally, it was the same source tree, and every KDE contributor (including translator coordinators) had commit access (except for certain directories).
The translations automatically appear in the released applications (it feels almost like magic:) ). And the translations files are automatically updated (with new/changes strings) each night¹. Easy peasy, and no hassle for the translators. (And when an application is renamed, moved, split into an application + library or have other changes that need changes in the translation files (this happens frequently), the nice people at KDE automatically do the needed changes to all the translation files.) What about different releases, how are they handled?
KDE currently has *four* branches, which we can call (slightly simplifying the names) KDE 4 stable, KDE 4 trunk, KDE 5 stable and KDE 5 trunk. Each application exists in one or more of these. From what I’ve understood (I haven’t developed a KDE application myself), it’s the application developer’s responsibility to define (using a Web interface, I think) which branch (and source repository?) the above branches correspond to. Typically, ‘trunk’ is set to a ‘master’ branch, while the ‘stable’ version is set to ‘release-xx’ branch (which change over time). The translation template files are automatically extracted from the source repository (using a special script in the source repository). The translators can choose to work on each branch (stored as a separate *directory* on the SVN server) separately (or perhaps just on the two stable branches), or in a special directory which (basically) contains the union of the files from each branch (so when you translate app.po, it will contain all the strings for ‘app’ which exist in at least on branch), using the ‘summit’ framework described here: http://pology.nedohodnik.net/doc/user/en_US/ch-summit.html
Footnote: ¹ I said that in KDE the translations files are automatically updated (with new/changes strings) each night. Note that it’s also possible to opt out of this (by placing a ‘magic’ file in one language’s translation directory), and merge the translation files oneselves, if one prefers. Some teams prefer this, and there are some advantages in getting to decide when (and how) to update the translation files. It gets a nuisance when your working copy doesn't match the copy on the svn.
Are you thinking of the case that the PO file has been merged with an updated template file while you had uncommited changes? Yes, that’s one reason to run the merging script yourself. (Though even if you have a conflict, it’s less of a problem than people make it out to be; you would just answer ‘mine-full’ or ‘theirs-full’ when svn asks how you want to handle the conflict.) -- Karl Ove Hufthammer -- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-translation+owner@opensuse.org