Karl Eichwalder napisał(a):
Additional note: Feeding the messages in a "private" repository always take time. Often it might be worth spending this time. In the long run I recommend to enhance the repository on Novell forge. If translation memories or other tools are missing, we should discuss them and then you can add them.
I'm sorry, I'm afraid I didn't get this paragraph.
I understand that this is due to updates made by developers, but I'd appreciate if you waited till the end of the round (and then schedulle another one), or explicitly announced on the list, that an update was checked in.
There are conflicting goal. The sooner the messages are in, the sooner translators can work on them, and test them.
I understand this perfectly. I have to admin, that it wouldn't be much of a problem, if it hadn't been for two fectors: 1) since I assumed that translation round equals total string freeze, I allowed myself to send the files to my colleagues instead of encouraging them to update their local copy of Novell repository every time they start to translate. 2) the prolonging downtime of the Novell repository made me think, that I was right to do so. Do you have any statistics on how many strings you usually have to update during a translation round? Or rather rough estimates, as opposed to exact statistics. Do all of them have a bug report associated with them? Maybe we could make an mail alias that would forward bugmail to all l10n coordinators, and that would be CC'ed to every such a bug? This would make it easy to track the updates for us.
Yes, line numbers are sometimes difficult to handle. We can discuss the --no-wrap option. In the very past, developers and translators aked for it. Yes, you are not meant to update translations if files only differ in line numbers and wrapping. Before diffing it mostly works best to normalize the files first using msgcat without any option or with --sorted.
I think as well, that the --no-wrap option is a good idea - it makes it easy for examlpe to quickly diff the po files and look for new strngs by greping msgstr "". (Without --no-wrap msgstr "" may not only indicate a new string, but also a string that has been wrapped). Also, thank you for the hint on normalizing the po files - it seems very useful. Thank you for your time on this. Best regards, Stanisław Małolepszy -- Aviary.pl l10n team http://aviary.pl --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-translation+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-translation+help@opensuse.org