On Mon, Oct 5, 2009 at 12:54 PM, Milo Casagrande <[email protected]> wrote: > Hi, > > 2009/10/5 Matthew East <[email protected]>: >> >> 1. Since it's the translators who often pick up these items, we should >> encourage translators to start working on the docs well before the >> string freeze. The reality is that most of the work they need to do >> can be started earlier without the work being wasted. And as you say, >> the package is uploaded relatively regularly so the translations are >> normally up to date. Do translators think this is realistic? > > Well... it depends... If we start translating something early in the > process, we might do that work twice, since strings may change. > In this case, if we really start translating early and we find an > error in a string, file a bug+patch, we will end up re-translate again > that very string, since for Launchpad it will be a new one and it > won't have any suggestions (as long as things have not changed in > Launchpad)...
Yes, that's true. But by way of compensation - you would have helped to find a bug and to have it fixed, and the re-translation of such strings would be necessary in any event! The majority of strings won't change, especially those which don't have bugs... >> 2. We could set up an automatic ppa upload with a package that is >> always up to date. I don't know how to do this but I've seen that some >> other teams have done so. That would need to be coupled with >> invitations to testers... > > Even the HTML version of the docs could do if it's easier to set up... We have that on doc.ubuntu.com. The site could do with some work though! >> 4. We could get the regular testing community involved in testing the >> docs so that testing documentation is a part of the regular testing >> regime - http://testcases.qa.ubuntu.com/ > > Another (probably drastic) idea could be to have the string freeze one > week earlier than it is now, and in that week do a strings review, > maybe seeking help from translators too. I would say that this would be best implemented as a "soft" documentation freeze which we could implement on our own, without reference to the main release cycle timetable. So we could specify that major new documents or sections should be ready by UI Freeze, and then the remaining period should focus on updating existing documentation and fixing bugs. This is something that we've discussed in the past but has never really caught on, perhaps because it's difficult to enforce it, as most work tends to be done during the end of a release cycle!! -- Matthew East http://www.mdke.org gnupg pub 1024D/0E6B06FF -- ubuntu-translators mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
