On Thursday 07 April 2005 08:30, Christian Perrier wrote: > Quoting Frans Pop (aragorn@tiscali.nl): > > But merging changes from trunk to sarge will still be possible even > > if you release from sarge. > > If a diff that is merged from trunk contains any kind of translation > > updates, that would break the master PO file mechanism. This was the > > reason the update scripts had to be disabled for RC3. > > > > So, if we keep the master PO file mechanism, I think we should always > > exclude any changes in translations when merging changes from trunk. > > Well, if changes are merged from trunk, then we can safely assume that > indeed they do no include string changes, right? I don't think so; they will have to be excluded when making the diff. A diff from r X to r Y can easily also include translation changes. Any rebuild of a package generally leads to changes in po files. You are talking about string changes for English I think. I am talking about both changes in the English strings and translation corrections. Also, there is no guarantee that there will be no strings added or changed for point releases. > So, for packages we are doing this, the strings are already there in > the sarge master files. > > The only problems which may arise are the case where a master file is > updated in trunk, but not in sarge. Which would be the responsibility of the translators. > In that case the individual PO files coming from trunk are newer than > the sarge ones...but would be replaced by those from the outdated > master file. > > So, my conclusion is that we should keep the sarge master files synced > with the trunk ones. > > What I imagine is a scheme where translators only commit to trunk > master files. The changes are then merged to the sarge files by a > script run from gluck and l10n-sync is run on sarge branch. Automatically? Without anyone looking at the content of the changes? What happens when new strings are added or existing strings are changed or dropped in trunk? Sounds like a bad idea to me... > > IMHO we would significantly reduce the risk of errors if we drop the > > use of master files in the sarge branch. > > This is another possibility, yes. > > But this will need translators to make updated to individual PO files > for sarge packages in case they correct errors which affect both > branches. In that case, the error correction will never go to sarge if > the package is released directly from sarge without being merged from > trunk first. Yes, but that would at least put the responsibility for updates with the people who know the language: the translators. > We can avoid that by *always* pick up PO files from trunk even when > releasing from sarge directly with no merge from trunk. However, this > adds complication to the release process and I'm afraid this would be > forgotten in some cases. Which would not work if strings have been changed or dropped in trunk that are still present in sarge and is IMO more difficult to manage when working from one huge PO file than if you look at one package at a time. (As probably a limited number of packages will be changed in any point release.) IMO the Sarge branch should be treated as a separate environment, both for code and translations. Automatic changes by the merged PO file mechanism (resulting in loads of commits) only helps to obscure the real changes made by translators and makes keeping track of changes more difficult. Having only the individual po files to worry about in the Sarge branch will make it easier to merge changes from trunk that are wanted and leave out others.
Attachment:
pgphzJrzfJOKQ.pgp
Description: PGP signature