[kde-doc-english] Sorting out backports/string freeze schedule

Wed Aug 17 20:09:32 UTC 2011

Am Dienstag, 16. August 2011, 08:14:32 schrieb T.C. Hollingsworth:
> On 8/15/11, Burkhard Lück <lueck at hube-lueck.de> wrote:
> > Am Montag, 15. August 2011, 15:32:57 schrieb T.C. Hollingsworth:
> >> I just realized that Kate's new folding stuff shouldn't go into 4.7,
> >> like all of the other changes in branches/work/doc so far.
> >> 
> >> How should I go about separating these out so they don't get
> >> backported?  Commit them to git separately?  Hold them in
> >> branches/work/doc until around 4.8 release time?
> > 
> > If that stuff is ready please commit to git master and add a note to
> > http://techbase.kde.org/Projects/Documentation/KDE4_(health_table)
> > stating the version (kde 4.8) and please add a comment like "Do not
> > backport to 4.7".
> > If there are updates also valid for 4.7 please try do commit separately
> > so it
> > is possible to backport that. CC this list or add the info to the Doc
> > Health table.
> 
> Sounds good.
> 
> Unfortunately Adrian already committed the new folding stuff, but I
> guess I can add a note to the health table that indicates not to
> backport that particular commit.
> 
> >> I wouldn't mind merging them into the branch myself if I could be
> >> told/be pointed at a schedule of when it is safe to do so.
> > 
> > You are not allowed to merge any single character change in the docs to
> > 4.7, this branch is completely string frozen.
> > 
> >> Come to
> >> think of it, I've looked around kde.org before for a 4.7 series string
> >> freeze schedule and couldn't find one.  That would be nice for
> >> planning out ongoing work to the plugins chapter and other docs
> >> anyway.
> > 
> > For 4.8 we'll have a release schedule similar to
> > http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule
> > 
> > Let me explain the string freeze issue:
> > 
> > Scripty aka the i18n tool chain and the translations teams handle only
> > two branches:
> > 1) trunk - Translations in trunk/l10n-kde4 and code/docs in trunk/[KDE|
> > extragear|playground] or the corresponding git branches
> > 2) stable - Translations in branches/stable/l10n-kde4 and code/docs in
> > branches/[KDE/4.x|extragear] or the corresponding git branches
> > 
> > Branch is always string frozen, trunk at certain times according to the
> > release schedules.
> > 
> > To break GUI string freeze in branch you always need approval from the
> > translators (kde-i18n-doc) and usually you'll get that.
> > 
> > Breaking DOC string freeze in branch is impossible for anybody - except
> > for the translators under certain rules
> > (see http://lists.kde.org/?l=kde-i18n-doc&m=126323170811427&w=2).
> > 
> > Btw I am a bit confused about your plans with the KWrite documentation in
> > work/doc.
> > 
> > Would you mind to elaborate please?
> > 
> > You splitted the kwrite docs into sevaral parts similar to kate's, If the
> > splitted kwrite docs go into git, the existing doc translations have to
> > be splitted by the translation team as well.
> 
> Well, most of the new stuff is an exact copy from Kate, and I was
> hoping splitting it would make copying translations easier, since they
> should already be translated for Kate and the only change in either
> was flipping &kate; to &kappname;.  (Not to mention that a monolithic
> docbook with everything in there now would be ridiculously long.)
> 
> But, I've been thinking about it, and even though everything I copied
> over is technically valid for KWrite, a great deal of it will probably
> never be used by someone with just KWrite installed.  (e.g. anybody
> who would be writing highlighting XML for katepart probably will have
> kate installed anyway, so we could just point to the kate docs for
> that).  I think there's one section of advanced.docbook that would be
> better suited in part.docbook, and then that could be elided from
> KWrite too.  The vi mode stuff could probably go as well.  I'm not
> entirely sure about regular expressions, methinks there are some
> people with just KWrite who might find that useful.
> 
> The only thing I really want to keep is part.docbook.  That had some
> stuff I linked to in kate/configuring.docbook but had to remove on
> sync to kwrite because it didn't exist there (as you noticed when
> translating).
> 
> At any rate, if it will make translating easier, I can certainly
> revert KWrite to one docbook and just copy/paste the much smaller
> amount of new stuff we'll keep in there instead.  As I said in the
> previous thread about this, I'm trying to make things easier for
> translators with all this new stuff coming over from kate but wouldn't
> be surprised if I'm overthinking things and actually making it harder.
>  ;-)
> 
I really appreciate that you care for the translators, but they do not need 
the same file layout for two docs with similar/identical strings to translate.

With the current situation of kate (several docbooks) / kwrite (one docbook) 
translated docmessages can be either reused via the translation memory of 
Lokalize or with summit 
(http://techbase.kde.org/Localization/Workflows/PO_Summit)

The only real impovement for translators (and documentation maintainers) would 
be to split off one or several parts of the kate/kwrite docs (sect, chapter 
etc) into docbooks, which are pulled in by both docs.
Digikam and showphoto eg share one docbook and on my todo list is something 
similar for the shared parts of konquerors/dolphins documentation-

From my pov as translator I'd say try to keep the docs layout as simple as 
possible for you as doc mantainer and then we (translators) will follow that, 
beeing happy to have up to date documentation to translate.

-- 
Burkhard Lück