On Fri, 25 Sep 2009 18:09:55 +0200 Hannes Magnusson <hannes.magnus...@gmail.com> wrote:
> On Fri, Sep 25, 2009 at 16:33, Lars Torben Wilson > <larstor...@gmail.com> wrote: > > I will look into the options (reverting; updating the translations, > > etc) before continuing. If anybody has any other suggestions, I am > > all ears. > > Reverting wont help. > Our "up2date" system is very broken. The checks are against revision > numbers, which means any change whatsoever will render an translation > out of date (be it comment changes, BOM removal...). > When making "useless" changes to bunch of files we try to detect if a > translation file is up2date before the change. If it was up2date then > those files need to get their EN-Revision revision bumped. > This was fairly trivial in the CVS days (few lines of PHP code to grep > the revision numbers from en/* and translation/* and cmopare them), > but could get a bit tricky with SVN as the revision numbers are not > per-file... > > -Hannes Hm. Seems I've set myself up for a bit of work here. I have checked out modules/doc-base and grepped around it for a while. Seems like quite a few of the translations still have many files with "EN-Revision: 1.nn" or "EN-Revision: n/a"--so they haven't been updated to SVN version numbers yet. As for the rest, the EN-Revision varies quite a bit. I had made a full copy of my fresh en/ checkout just before committing the sweeping change to the local-variable comment. It seems to me that if I compare the EN-Revision tags in the doc-all/ language trees against the $Revision$ tags in the en/ tree, I should get a list of which translation files were up-to-date with their respective en/ files before I bunged things up. With this in mind, I've written a small script which compares these tags and have found, for instance, that Simion's /ro tree was completely up to date, while the /zh tree was mostly up to date but had a few files left which were still out of date. So I think that I can restore things to (near) normalcy by bumping the EN-Revision tags in the doc-all/$lang files to the current SVN $Revision$ number of their corresponding /en files in those cases where those doc-all/$lang files were up to date before my massive commit, while leaving the others alone (as they were out of date anyway). Does this make sense? I don't want to risk making another huge commit error in trying to fix the last one. Thoughts? Torben
