You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <e....@gmx.net> on 2004/10/05 20:58:01 UTC
RFC: Revised translations on branch maintenance scheme
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
Re: RFC: Revised translations on branch maintenance scheme
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Tue, 5 Oct 2004, Erik Huelsmann wrote:
>
> Long mail ahead! Please read, because it involves direct branch commits.
>
+1.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
SVN website "links" section.
Posted by Alexander Kitaev <al...@tmate.org>.
Hello All,
I've already wrote about project I'm participating in (pure java subversion
client library), and also I've asked about possibility to place link to my
project web site in the subversion web site "links" section.
As far as I know there is certain demand in such a library in the developers
community, and, on the other hand I would like to make more people to
evaluate current early access version of the library to make it more stable,
useful, etc. That's why I'm asking about placing link to the library home
page in the links section. I suppose such a link will help people interested
in pure java svn solution to be aware about my project. So far I get no
answer from subversion developers and maintainers, so I'm reposting my
question :) May be there are certain cirterias project should meet to be
referenced on the svn website?
Pure Java SVN Client Library: http://tmate.org/svn/
Alexander Kitaev.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Revised translations on branch maintenance scheme
Posted by "Øyvind A. Holm" <su...@sunbase.org>.
On 2004-10-05 22:58:01 Erik Hũlsmann wrote:
> 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.
> [...]
> 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'
This looks as a Good Thing™. Have been testing the script with ancient
versions of the files, and it seems to do the job right. No doubt this
will make life easier for the translators. +1.
Regards,
Øyvind A. Holm
---------------------
cat /dev/urandom >SCO
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Revised translations on branch maintenance scheme
Posted by Lübbe Onken <l....@rac.de>.
Erik Huelsmann wrote:
> 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'
In principle I like this solution, but I've got a few things to add.
Since I translate on windows boxes, 'make locale-gnu-pot' (the find
stuff) doesn't work for me. Maybe I should try to hack my current script
into python so that an alternative exists for windows users.
I think it would be a good idea to put subversion.pot under version
control. I know that it can be created easily, but on the other hand
this would solve the above mentioned problem for people who do not
translate on Unixes.
That's what we do in TortoiseSVN. We've got an official reference .pot
file for everyone and people can translate without having to check out
the entire source tree! They just grab the current po and pot for their
language and go ahead.
Take a look at: http://tortoisesvn.tigris.org/translations.html.
We've got eighteen languages including english and I think the main
reason is that the translation procedure for TortoiseSVN is a lot easier
than for Subversion.
Take a look at:
http://svn.collab.net/repos/tortoisesvn/trunk/Languages/translations.txt
for our translation procedure.
To run 'make locale-gnu-po-update' requires me to check out (or switch)
the entire source tree twice, once for trunk and once for the branch.
This is a nightmare at home where I only got a 64K line...
Summary
-------
Put Subversion.pot under version control:
+ Life is easier for translators (no huge checkouts)
+ works on every platform
+ po-merge will still work the way you suggested
- Subversion.pot may be out of date, but since you run the translation
status checks daily already, you could also run 'update-pot' once a week
> 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
Could you also add a check for people (like me) who forget to change the
"Last-Translator" line in the .po file :-)?
Cheers
- Lübbe
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Revised translations on branch maintenance scheme
Posted by kf...@collab.net.
"Erik Huelsmann" <e....@gmx.net> writes:
> 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 the part of the proposal that most wanted comments was this
paragraph. So here's my comment: I agree with your reasoning :-).
> 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?
+1!
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Revised translations on branch maintenance scheme
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Wed, 6 Oct 2004, Karol Szkudlarek wrote:
> > 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.
>
> I don't think that 100% translation is mandatory. For instance:
>
> if translations for Malagasy contains for example a 100000 (big number)
> messages and will be almost complete and have only several (<10)
> untranslated messages which are errors which occurs very rarely and in
> very specific situations; so then I can't tell that translation is not
> good to put it to the branch and even release it. That <0.01% is small
> factor which decides about having Malagasy translation or not. This is
> not good.
>
OTOH, if you have very few messages, why not just take the little extra
time to get them translated? But, I've also argued the other way earlier
on this list, also because some obscure error messages shouldn't block the
whole translatin from being included. However, if those don't get
translated, then we have a maintianer problem and the translation can wait
until that's fixed.
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: Revised translations on branch maintenance scheme
Posted by Karol Szkudlarek <ka...@mikronika.com.pl>.
> 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.
Hi!
I don't think that 100% translation is mandatory. For instance:
if translations for Malagasy contains for example a 100000 (big number)
messages and will be almost complete and have only several (<10)
untranslated messages which are errors which occurs very rarely and in
very specific situations; so then I can't tell that translation is not
good to put it to the branch and even release it. That <0.01% is small
factor which decides about having Malagasy translation or not. This is
not good.
This is my opinion... :-)
Karol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org