[kde-doc-english] commiting patches

[Burkhard Lück]

Am Montag 14 November 2005 16:23 schrieb Philip Rodrigues:
> > My own opinion is: PLEASE do commit but always CCMAIL the commit log to
> > the program maintainer!
>
you mean the documentation maintainer/last author? or perhaps this list?

I have never seen a CCMAIL:program maintainer in the commits for my 
documentation bugs.

> Agreed. One minor thing - check the docs with checkXML rather than
> meinproc. There are one or two corner cases where errors aren't picked up
> by meinproc but are picked up by checkXML.
>
> Also, apologies that your bug reports weren't picked up sooner - most of
> the docs team have been quite busy with RL, I think, so we've got a bit
> behind with things.
>
> > A question that is worrying me: are these commits automatically synched
> > with trunk?
>
> Not that I know of. We're a bit uncertain of what to do about trunk (since
> any changes we make there could quite likely become obsolete by the time
> KDE 4 is released). Does anyone have any thoughts?
>

stable synched with trunk?

Doesn't say the policy no commits to stable?

Lauri Watts on 2004-03-30 13:44:08 in kde-i18n-doc regarding policy for 
updated original documentation::
"The policy is that the branch is completely frozen, with no exceptions."
 
Nicolas Goutte today in kde-i18n-doc
"Basically, the rule is that no strings should be added or changed during a 
message freeze.
They are two kind of exceptions:
- the string is untranslatable
- the possibility of a severe misunderstanding of the message, especially with 
a high probably that due to this misunderstanind, the user would lose data."

So I have to commit to trunk?

I don't like this policy, try to explain why:
The errrors I mean are really bugs concerning the documentation, like:
1. menuitems, labels, buttons in gui, but not in the command/menu reference of 
the documentation
2. obsolete menuitems, labels, buttons no longer in gui
3. menuitems moved to other menus
4. wrong names/spelling of menuitems, labels, buttons
5. chapters in the documentation about functions of an application, which are 
no longer implemented

Have you ever watched an inexperienced user looking for help in a handbook, 
which is outdated or has errors in the command/menu reference?

To me thats the same kind and severity of bugs, which are fixed in the code or 
in the gui-strings in stable, so it should be allowed to do this also for 
these bugs in the documentation.

And there is a big difference between changes in strings in the gui and the 
documentation. 
Changing a string in the gui means fuzzy entries in every language.po, so the 
user will see an englisch string instead of the supposed correct translated 
string in his language.
For the documentation the situation is completely different. As long as the 
translation teams have already translated the docs and generated the language 
docbooks before the bugfix, nothing is different to the situation we have 
now, only the stats are effected.

Only if the translation teams generate new docbooks for the concerned 
kdemodul after the bugfix, they also have to updated the translation for the 
fixed documentation.
And this update is very easy, i have written some python scripts to 
semi-automate this task.

But now some teams have the chance to improve the documentation for there 
language, and that's the sense of an bugfix and translation release.

With the current policy we have translated gui messages for the current 
release, together with translated documentation (sometimes? often?) for the 
previous release.

What do you think?

Burkhard Lück