From kde-i18n-doc Wed Nov 26 23:18:37 2014 From: Albert Astals Cid Date: Wed, 26 Nov 2014 23:18:37 +0000 To: kde-i18n-doc Subject: Re: i18n and direct builds from a source repository Message-Id: <3502304.MAtI6yG667 () xps> X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=141704393924771 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart1847598.gddCpMtFIp" --nextPart1847598.gddCpMtFIp Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" El Dimecres, 26 de novembre de 2014, a les 14:09:36, Thomas Friedrichsmeier va escriure: > Hi! > > As a short introduction, I'm from project RKWard. We're in the process of > migrating from SF.net to KDE, and we have only just arrived on git.kde.org, > last week. So forgive me, if I have not quite understood some things, yet, > or go into unneccessary lengths at some points. > > snip > Have you tried https://build.opensuse.org/ ? I have no idea how it works but it creates packages for lots of distros and maybe you can script it properly (unlike launchpad) to run releaseme for you? > 5. A suggestion: > So what could be a way to improve on this? Here's my idea. I am willing to > put some effort into implementing this, too, if you agree that it might be > a good idea: > > - In SVN, create a new subfolder "export" under l10n-kde4 and l10n-kf5. > - In this, interested projects could place a config file, like e.g.: > rkwardrc > [main] > projectname=rkward > projectpath=playground/edu > doc_destination=doc/ > [po_globs][rkward*.po] > destination=po/{PONAME}.{LANG}.po > [po_globs][if_you_really_need_this_too.po] > destination=elsewhere/{PONAME}.{LANG}.po > [doc_globs][*.docbook] > destination=doc/{LANG}/{DOCNAME}.docbook > - Scripty will parse this rc file, and copy stuff to subdirectories of > "projectname": > rkward/po/rkward.de.po > rkward/po/rkward.fr.po > rkward/doc/en_US/index.docbook > ... > - Of course, scripty will also do postprocessing similar to releaseme. > Importantly, stripping stale messages form translations. Also, it should > probably strip all message comments, replacing them with > #. i18n: Translation export. DO NOT EDIT. > This is to avoid any danger of confusion, but should also help to reduce the > additional noise: Mere changes in line numbers would not cause an extra > commit. > - Projects can supply their own CMakeLists.txt, and place them where > appropriate. Of course this could also be handled in analogy to what > releaseme does. For a first sketch, we'll keep it simple. > - Similarly, projects would be responsible for cleaning stale docs and > catalogs, for now. Scripty would only add (and overwrite) things. > > 6. So why would this help? > - Fetching l10n, and merging it into a source tree would become a rather > trivial operation: A single "svn export / co / up" is needed to get all > that, and should be a matter of seconds in most cases. This makes it easy > to document, and could even be integrated into a project's build system > with just a few lines of code. > - Works out of the box with launchpad, making it really, really easy to > provide dailies with the latest in code _and_ translations. And should be > similarly easy to build into most other systems that support > repository-based builds. > - Makes it easy to see just what will be added to the sources, instead of > looking like black magic to the non-initiated. > > 7. What does it not help with? > - Will not "push" updated translations to the user / build system by itself. > Only makes it easy to fetch them. > - Adds yet some more noise to SVN. Although that should be quite limited in > comparison, if the file context info is stripped as suggested. > - All logic currently in releaseme will have to stay in releaseme (unless > and until all projects use this method for i18n). > - More work to do for scripty. However, overall ressource strain should not > increase, and might even decrease, assuming any projects requesting exports > would otherwise run releaseme on a daily basis or more often. > > So - if you've made it all the way to this point - what do you think of the > suggestion? I don't think it's a good idea to copy files around, and it will most probably end up in cruft noone will remember to update. releaseme already knows how to do all that work, you have two problems with it: a) It's an additional piece of code b) It's slow About a) the same can be said about your suggestion, sure it's argably a "simpler" additional piece of code, but the user still has to do extra things About b) yes, svn is slow if you want to fetch all languages, but unless you're actually creating a source tarball, you will most probably want a single language, which if added, would make it much faster. Now, adding that "checkout single language" to releaseme is probably a bit weird, since that's not what releaseme is for. But it should not be "that hard (TM)" to do a script that is run as: $ fetch-l10n rkward de * Goes through the Messages.sh and parses which .pot files are created * Gets http://projects.kde.org/kde_projects.xml and finds out the virtual module of rkward * Knowing the virtual modeule of rkward and the .po it needs goes to svn fetches them and runs scripts/autogen.sh in them This still has the problem of your daily builds though if no script can be run Cheers, Albert > > Regards > Thomas --nextPart1847598.gddCpMtFIp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlR2X9AACgkQ/lREvmcCFhtrQQCfY6tQRwTa5CQz8i8bYuA4/pEe IfoAn2CLz49c4wzi3+CCAeKCGg98xF1x =wBFS -----END PGP SIGNATURE----- --nextPart1847598.gddCpMtFIp--