[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: [RFC] Clean up the language docbooks
From:       Burkhard =?iso-8859-15?q?L=FCck?= <lueck () hube-lueck ! de>
Date:       2010-08-16 14:34:03
Message-ID: 201008161634.03531.lueck () hube-lueck ! de
[Download RAW message or body]

Am Montag, 16. August 2010, um 11:45:23 schrieb Chusslove Illich:
> > [: Burkhard Lück :]
> > At some point in kde4.x I used a brute force method for that. I removed
> > all german docbooks and generated the docbooks again. That gave a clean
> > german documentation. [...]
> 
> Hm, what about when a complete subdirectory should be gone? E.g. when going
> through the report of obsolete docbooks you provided for us, I was checking
> where I should really delete only those docbooks, and where the whole
> subdirectory (e.g. kdebase-runtime/userguide/).
> 
This usecase is not covered by the script so far. Of course such a 
functionality could be added.
But in my usage (once cleaned up language documentation completely and do that 
than regularly) I don't need that.

> >> [: Chusslove Illich :]
> >> This script that you use to detect out of date stuff, is it somewhere in
> >> the repository?
> > 
> > [: Burkhard Lück :]
> > No, where to upload it? Somewhere in l10n-support?
> > [...]
> > But be warned: Writing the scripts was only intended for my personal use
> > to maintain the german documentation, and later on I extended some of
> > them to handle all languages.
> 
> Since it's mostly hardcoded, could you minimally adapt it to behave
> similarly to other branch-bound scripts? This means that it would be both
> in branches/stable/l10n-kde4/script/ and trunk/l10n-kde4/script/, and if
> run by:
> 
>   $ cd WHEREVER/l10n-kde4/
>   $ scripts/detect_obsolete_doc.sh
> 
> it would give out the report for all languages, and if run by:
> 
>   $ cd WHEREVER/l10n-kde4/
>   $ scripts/detect_obsolete_doc.sh LANG
> 
> it would give out only the report for that language.
> 
> Of course, if you could make it also branch-independent, then the best
> place would be trunk/l10n-support/scipts/.
> 
> > So you'll find german comments, hardcoded paths for my checkout dirs, no
> > proper usage message, no proper error handling etc.
> 
> I think that so long as it can be run as above, it would be quite usable as
> it is.

I have commited the scripts + a library to trunk/l10n-support/scripts, they 
are branch-independent now.

$ python l10n-support/scripts/checkoutdateddocbooks.py

Usage:  python path/to/checkoutdateddocbooks.py path/to/10n-kde4/

Output: print all index.docbooks with date != date in uk index.docbook to 
stdout


$ python l10n-support/scripts/checkobsolete.py 

Usage:  python path/to/checkobsolete.py lang path/to/10n-kde4/

Output: print obsolete (moved/removed/renamed) messages/docmessages/docbook to 
stdout
        lang = language subdir in l10n-kde4
        use lang = all to check all languages

In case of any question, just drop me a note or ask here.

> 
> >> [: Chusslove Illich :]
> >> You mean to clean up in one week this once, or once every week?
> > 
> > [: Burkhard Lück :]
> > Once a week before docs.kde.org is updated (afair friday). That should
> > not be much work once the language docbooks are cleaned up.
> 
> I'd find that a great service, but fair to accept only if it would really
> take you negligible time. Otherwise, just make the detection script
> available and scold us from time to time :)

Once all language documentations are cleaned up, you barely need the script 
checkobsolete anymore, just follow the latest docmessage entries in 
process_orphans.txt, that is really no big or time consuming deal then.

Handling the outdated language docbooks seems to be different. 
What is better - a slightly outdated (but in general still valid) translated 
documentation or an up to date english documentation?

Of course every documentation where (datelangdoc older dateendoc) AND 
(datelangdoc<=2006) AND (dateendoc>2006) has to be removed asap.

-- 
Burkhard Lück

[prev in list] [next in list] [prev in thread] [next in thread]