AppStream Upstream Metadata: The next steps

[Burkhard Lück]

Am Freitag, 18. April 2014, 21:11:10 schrieben Sie:
> 2014-04-18 20:50 GMT+02:00 Burkhard Lück <lueck at hube-lueck.de>:
> > Am Freitag, 18. April 2014, 16:25:40 schrieb Matthias Klumpp:
> >> These scripts illustrate how translation of the XML can be done in
> >> KDE. I would kindly ask the l10n-script developers to take a look at
> >> it any maybe integrate it at the proper places, because they know the
> >> code way better than I do.
> >> 
> >> The scripts can be found at:
> >>  http://people.freedesktop.org/~mak/appstream/kde-asmetadata-l10n.tar.gz
> >> 
> >> (I also included a demo XML file)
> >> I wanted to post that to Reviewboard, but couldn't find a project for
> >> Scripty.
> > 
Please use https://svn.reviewboard.kde.org/groups/l10n/ for your patch

> > Quoting my comment on https://git.reviewboard.kde.org/r/117609/
> > 
> > Please have a look at the recent changes in
> > http://websvn.kde.org/trunk/l10n-kde4/scripts/?sortby=date#dirlist
> > 
> > extract-xml.sh
> > update_translations
> > fillxmlfrompo.py
> > 
> > These changes are about a similar problem, ectracting strings for
> > translation from mimetype xml files and fill the xml files with the
> > translations.
> Some of these files already existed back in the days. From what I've
> seen, the code takes the mime-xml, extracts interesting tag
> (<comment/>) performs some hacks so intltool likes it (<comment/> =>
> <_comment/>) and then does similar stuff my examples do (but with
> intltool instead of itstool, which IMHO is mot really nice for this
> purpose (I love intltool otherwise!)).
> I also don't fully understand the need for XmlMessages.sh in the source
> tree... So, because of this and especially because of:
> # Note to developers:
> # there are not many comments in this code to avoid to slow down the code
> # So please look also in the svn log to have comments about the code
> I would need help from someone experienced with the l10n workflow and
> especially the l10n code to integrate the changes - that stuff is
> really hard to understand if you don't know the details and if there
> are zero comments explaining things[1]. The UML helps a little bit,
> but it still leaves lots of questions.
> I think with the scripts above it's trivial for someone who knows the
> code to call them from the appropriate places and make the necessary
> adjustments ;-)
> Cheers,
>     Matthias
> 
> [1]: Maybe long-term it would make sense to attempt a Python rewrite
> of this? (there are currently bits of C++, Python, Perl, Sh and Bash
> in this - Esp. calls like "g++ -O2 -march=nocona -o apply
> scripts/applycontext.cpp" in the generation code make me wonder...)

Thanks.
-- 
Burkhard Lück