Long mail ahead! Please read, because it involves direct branch commits.
History
=======
Recently Oyvind A. Holm (alias sunny256) committed a change to TRANSLATING
adding a new section on maintaining translations on branches. In his piece
he describes how it has to be done with the current restriction of
committing to trunk and backporting to the branch. His scheme involves
quite some changing, reverse merging and changing again. The system turns
out to be quite complex.
One of the problems which make branch maintenance difficult is that one is
supposed to run 'make locale-gnu-po-update' in order to make sure the
translation fits the branch. Because this updates the line numbers in the
file, subsequent merges are almost certain to result into conflicts. The
msgmerge tool which comes with gettext is not suitable for doing branch
maintenance, so it can't relieve the problem.
Tobias has taken some time to hack up a po-merging tool which does not have
the same problems with merging from trunk to branch as msgmerge. This tool
has a crucial role in the next section. At Tobias' and my request has C
Mike updated svn.collab.net hook-scripts to do not only UTF-8 checking but
also format checking on committed po files. Invalid po-files should now be
rejected in the pre-commit hook.
The new procedure (to be added to TRANSLATING after discussion)
=================
I propose - in light of making things work with translators instead of
against them - a new scheme for updating translations on branches. These
are the rules / steps involved in my proposed scheme:
1) All (major) translation development happens on trunk
Only after a translation has been completely (100%) translated on
trunk, can it
be considered for copying to a release branch.
2) Updating branch translations is done with the new po-merge
2 operations are allowed on branch translations which allow mass
file updates: po-merge and 'make locale-gnu-po-update'
With this scheme almost all messages can be easily merged to the branch.
Remain those messages for which there has been no translation on trunk, but
which do exist on the branch. For code changes which cannot be committed to
trunk and backported to a branch a patch is developed with which normal
voting procedures apply. Since there is no voting requirement for porting
translation changes from trunk to a branch, there would be no voting
requirement for a patch like that. Without the need to vote it seems kind
of silly to require the patch be made. Thus direct branch commits seem to
follow from our own rules for this kind of change.
I think that in this special instance branch commits are alright, since:
- there is a pre-commit hook to catch the worst failures
- the number of messages on a branch which have no translation (ever) on
trunk is typically quite low
Comments?
bye,
Erik.
--
+++ GMX DSL Premiumtarife 3 Monate gratis* + WLAN-Router 0,- EUR* +++
Clevere DSL-Nutzer wechseln jetzt zu GMX: http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 5 22:58:18 2004