Is it possible to auto generate mails to i18n, when there are string changes in the pot file. It would make keeping resources in Tx up to date a lot easier.
It would be very welcome. At least KDE has some "magic" to do so automatically, see e.g. http://websvn.kde.org/trunk/kde-common/svn/hooks/post-commit.pl?view=markup
CC: (none) => bald
I think there was something similar on mandriva svn, but can't find the script that was used.
CC: (none) => boklm
As far as I remember there was/is no such thing in Mandriva or at least it was/is not used, though there were times when Pixel or Thierry sent more or less regularly an email to the i18n list.
The one mentioned in this thread : http://lists.mandriva.com/cooker-i18n/2010-02/msg00023.php
I stand corrected - looked at Mandriva i18n archives http://lists.mandriva.com/cooker-i18n/ and remembered there really were such automatic emails in the first half of 2009. Have no idea why it was discontinued or where to look at relevant script.
We could add a post-commit hook for that, but this would requires some change puppet side.
CC: (none) => misc
Ok, I think I have a proposal that would not be too specific.
Assignee: sysadmin-bugs => misc
I think it should be ok. But later, I think we should migrate to something more generic so people can subscribe freely to any change they want.
Status: NEW => RESOLVEDResolution: (none) => FIXED
It seems it didn't work, I have to debug this.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Ok, I forgot about this, but I think I found the problem, I just send the mail to the wrong address. I committed a fix, and I will update the translation of identity for that. The mail is sent on mageia-i18n@
After testing, it seems to not work. Further debugging have show that's because the perl module we use ( Svn::Notify::Config ) is only able to match on the path of a fle, not the filename itself. However, I was unable to remotely understand the code :/
Ok, I had a stroke of genius, and found the code responsible, and this is in SVN::Notify, function prepare_recipients. I guess replacing svnlook dirs-changed by svnlook changed + some filtering would do the trick.
FYI : https://github.com/theory/svn-notify/pull/1
Any news on this?
pinging. because nothing happened to this report since more than 3 months ago, and it still has the status NEW or REOPENED @ misc Please set status to ASSIGNED if you think this bug was assigned correctly. If for work flow reasons you can't do that, then please put OK on the whiteboard instead.
CC: (none) => marja11
Priority: Normal => release_blocker
Priority: release_blocker => High
CC: (none) => dglent
CC: (none) => filip.komar
CC: (none) => mageiaHardware: i586 => AllAssignee: misc => sysadmin-bugs
*** Bug 6377 has been marked as a duplicate of this bug. ***
CC: (none) => thierry.vignaud
This one _MUST_ be fixed before next release. It would make developer & translator life quite a lot easier.
Priority: High => release_blockerSeverity: normal => critical
CC: (none) => rdalverny
Ping!
This is not release critical as it can be fixed at any time. But I do agree this should be fixed quickly. boklm will have a look as soon as possible
Priority: release_blocker => HighCC: (none) => ennael1
CC: boklm => (none)
I guess we can close this one as Colin did his magic some time ago.
Status: REOPENED => RESOLVEDResolution: (none) => FIXED