ons 2005-09-28 klockan 15:31 +0200 skrev Tomasz Kłoczko: > > Le mercredi 28 septembre 2005 à 13:56 +0300, Tommi Vainikainen a écrit : > > > On 2005-09-20T18:44:55+0300, [EMAIL PROTECTED] wrote: > > > > Tomasz, why did you need to do this everywhere? :( I really hope > > > > there are some good reasons for this. Anyway, please revert all these > > > > changes. > > > > > > Was there ever any conclusion for this thread? I see that Thomas has > > > done more this kind of commits after last message in the thread as can > > > be seen from > > > <URL: http://cia.navi.cx/stats/author/kloczek > > > > > I've been getting bounces for all messages to > > [EMAIL PROTECTED] ; it appears the cvs-commits-list mails have > > an invalid From: address :( > > How can I change this alias ?
As Ross said; http://live.gnome.org/UpdatingEmailAddress > > Trying to CC the @cvs.gnome.org address now, but last time I tried that > > one (for someone else) it didn't work either... > > Anyway .. resons: > > 1) Many .po files have incorrect content of c-format translated entries. > Keep not updated this files *creates real risk from security point of > view*. None of your ChangeLog entries listed this as a point of action. > 2) Many translators do not run "make update-po" before completting > translations and bring them (for example) one time per release > updated all .po files makes possible finish some work. > Many .po files have content not updated (update-po target) > by *year, two or ven more* and this plain proof of this kind problems. > Two years ago widely was used gettext without c-format entries > checking (this is why risk described in point 1) still is real). If you find any problematic translations, you should bug report this kind of problems to either the author of the translation, the team coordinator for the translation team for that language, or directly to the maintainer of the affected application. You should never ever commit any "fixes" *whatsoever* without approval. And even if you would have happened to have said approval to fix that type of problems, you should never ever alter any files that didn't have the problems in them. Because that was what your changes were doing - modifying all files, including perfectly valid files. > 3) Number of outdated lines with translations in some projects makes dist > tar balls larger by megabytes (example: evolution). In some cases it > takes around half of some files (usualy few procents). There are many perfectly valid reasons why some translators leave some unused messages in by purpose. Some of the reasons include that the translators may suspect that these messages are likely to be reused and do not want to translate them again from scratch. This can for example be when the original message had a typo and when that is likely to be corrected some day and the translator doesn't want to redo his work by then, but instead arranges a translation of the correct spelling right now, which then of course becomes a unused translation for the time being. Or this can happen when a similar message is likely to appear in the future for other reasons, or in order to help fuzzy matching in general. In many cases a few kilobytes of extra tarball size is a small price to pay for hours of saved work. Some kilobytes of disk space is cheap; man hours isn't. In any case, this is not up to you to decide. Maintainers may complain if specific tarball sizes are becoming a problem, and then a solution might be worked out with affected translators. Then, and only then, some course of action might be taken. > 3) Many GNOME projects have po/ directory ~up-to-date because > maintainers before release runs "make -C po update-po" and commit > changes (example: glib, gtk+, gnimeric, gimp ..) ~one time per release. > Seems noone says "it is incorrect" and/or "it makes translation harder". In that case you must have ignored any mailing list traffic for the last few years: http://mail.gnome.org/archives/desktop-devel-list/2003-May/msg00896.html http://mail.gnome.org/archives/gnome-i18n/2004-August/msg00161.html If you are claiming that noone complains, then you have not been listening for years. > 4) In case not commiting same changes by translators before someone will > commit changes added by update-po target translator only must merge > own/not commited yet changes using msgmerge command from > #<lang>.po.<rel> file created by cvs client and without loosing single > line can continue tranalation work. It's you who shouldn't touch other people's work without permission in the first place. If you feel otherwise, or feel that it's so simple to undo your changes if needed so there was no real harm in committing those changes in the first place, then you have totally misunderstood the rules of behavior for any write access repository, and should not be allowed write access to any repository within lightyears of range. > 5) update-po target do not trash any translations. Only comments not used, > adds some new entries and marks some entries as fuzzy. > > Now is used habit for stop few days before release chages around itroduce > new strings for translate. IMO best will be mark this point by "make -C po > update-po" and commit changes performed by project maintainer. > > Run "make -C po update-po" each time when something is changed in .c files > will be of course very stupid (will create big "noise" aroud po/*po files) > but one time per relase, and one time per three or two releases cuting > outdated string will allow keep this resources in good form (and possiby > comfortable for translators). Four points: A) Any such policy should be discussed first. B) Any such policy should be given approval by those affected (translators, maintainers). C) If there was any such policy, and you were the one chosen to do it, then that should be made clear beforehand. D) None of A), B), or C) applied in this case. > Q: reverte my changes ? Yes, "reverting" is the action of immediately undoing unauthorized or otherwise unwanted commits in the repository. The revertion is to be done by the person who erroneously committed the stuff, so as to not waste other people's time more than necessary. Not reverting when asked to is generally not an option: Committing unallowed changes is bad enough in the first place; not reverting the changes when asked to is a guarantee for being banned for life. Speking for myself, Christian _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
