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

List:       kde-i18n-doc
Subject:    Re: i18n and direct builds from a source repository
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-11-26 23:18:37
Message-ID: 3502304.MAtI6yG667 () xps
[Download RAW message or body]


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

["signature.asc" (application/pgp-signature)]

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