First I should say that I think this all look very good. Considering the proposed goals and the previous feedback, I think you have come up with some elegant solutions. Cheers.
> + we strongly encourage the application developers to follow the GNOME > development cycle. If a different development cycle is used, it has > to be documented to help contributors. If you remember from the previous discussions, this is a sensitive subject from a translations resource/translation completeness point of view. The objections were that having a large group of applications (I use the term widely), that has a well defined and common release schedule, makes for a easily definable goals and makes it easy to maximize translation performance with limited resources. This objection still stands, "strongly encouraging", does not give me a guarantee against untimely string changes and the concomitant loss of work, the way that the current workflow for the desktop module set to a very large degree does. However, if I try to look at this from a broader perspective, I do see some convincing "greater good" arguments for this decision. So although the objection is still valid, I think the proposed solution is a worthwhile compromise. (Lets just hope that "strongly encourage" means way more than 75% of the projects will follow, and not, like I may fear, less than 25% :)) I would like to elaborate on one very important thing that you mention, and that is that if a project chooses not to follow the GNOME release schedule, the key is information. So when/(if) this happens it has to be extremely visibly, preferably right there in l10n.org. So I would suggest as a technical detail to your proposal, that it is a _requirement_ for project maintainers of projects that don't follow the GNOME release schedule, to not only document it in their development fora, but also to publish a (tentative) string freeze and release date somewhere in the repository, so that it can be automatically parsed and published on damned lies. With regards to external translation tools I will reply in the new thread Andre has started. Regards Kenneth _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list