Consolidating the various freezes

[Jordan Mantha]

On 9/14/07, Soren Hansen <soren at ubuntu.com> wrote:
> On Fri, Sep 14, 2007 at 09:10:24AM -0700, Jordan Mantha wrote:
> > > I'm surprised, actually, that documentation has had any sort of
> > > freeze process. Being a descriptive work rather than a defining one,
> > > I think it makes sense to allow the documentation to be changed up
> > > until only just a few days before release (to leave a tiny bit of
> > > time to fix up compilation issues or whatever).
> > Try to solidify/proofread/bug fix a whole distro's amount of
> > documentation *and* get it translated in a couple days. It's not that
> > easy ;-)
>
> That's not what I'm saying at all.

I know, perhaps my ;-) didn't come through right.

> > Translators don't like having to retranslate strings they've already
> > translated. If we don't freeze the docs and allow time for translation
> > to take place with minimal changes then people get quite upset,
> > reasonably so.
>
> I disagree. In programs, there's generally very little space for strings
> in a user interface, so the wording needs to be very precise to
> correctly convey the intended message. Slight changes in wording often
> reflect changes in the functionality said string describes.
> Additionally, there are technical reasons why a changed string causes
> work for translators. Even a spelling mistake cannot be corrected
> withouth causing work for translators. With documentation, this is not
> the case. There are no technical reasons why the documentation must be
> kept in precise sync. There is no extra work to do for translators if a
> spelling mistake is corrected. Most often, the English documentation is
> the best, which is why that is used as the base of the translations, but
> essentially the non-English documentation could easily be written
> independently from the English one, as their purpose is a descriptive
> one, rather than a defining one.

Well, I kinda see your point but I'm not sure I agree. We are often
writing entire docs up until the string freeze, we aren't talking
about little changes here and there. Also, the job of the translators
is to translate what the documentation has written, not write their
own docs. If they want to write their own docs fine, but they
shouldn't be doing that when translating the doc teams works, that's
just wrong.

> > For the Documentation Team the doc freeze is quite important. We need
> > time to get everything proofread.
>
> Correct me if I'm wrong, but doesn't proofreading need to be over with
> *before* string freeze? Sure, proofreading is fun, but it's kind of a
> bummer to not be allowed to fix the speling mistaeks you find during
> said proofreading.

We try to do as much proofreading as we can before the freeze but
practically speaking a lot of proofreading is done after the string
freeze as well. The point of the freeze is to not add any content and
just fix bugs and make important changes. It's also a deadline for us.
If we had no deadline we'd be writing up until the day of release and
there would be very few decent translations and not as much
proofreading.

> > It's really not much different than software in this regard. We write
> > as much content as possible until the freeze and then go into "bug
> > fixing" mode until release.
>
> Maybe I'm misunderstanding something, but I don't see how it affects a
> translation of the documentation if you change something in the English
> one? You may have chosen to reword things or whatever to make things
> sound better, but what was there before might also have been correct,
> but just not very cleverly worded. The translation may have been really
> good the first time and might not need any changes to reflect *your*
> changes?

I'm talking changing how paragraphs and sections. Even if you do
change the spelling in English I believe that will show up in Rosetta
as a change to the string and it'll have to at least be reviewed
again.

> > The 2 issues we have are: 1. having to describe an every-changing
> > distro.  It's helpful then to have the doc freeze *after* the Feature
> > Freeze and UI Freeze, especially if screenshots are involved.
>
> Understood.
>
> > 2. giving enough time for translators to translate *before* the
> > release.  generally 4-6 weeks is good, in past experience.
>
> They can start any time they want? If they think the English
> documentation sucks, they are surely not bound by any sort of
> (unwritten) contract that their translation must match the English
> documentation?
Why not? It's translation. Unless I completely miss the meaning of the
word, translations are supposed to stick as closely to the original as
possible. I'd get quite upset if somebody translated the Packaging
Guide and decided to write their own content and disregard mine as
then it's not a translation of the Packaging Guide but rather another
work.

-Jordan