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

List:       kde-i18n-doc
Subject:    i18n and direct builds from a source repository
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2014-11-26 13:09:36
Message-ID: 22495558.gKGqK9tGbt () late
[Download RAW message or body]


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.

1. Problem statement:
- What do you have to do to build a development version of a KDE app?
In general, just
  git clone git://anongit.kde.org/something.git
  cd something && mkdir build
  cmake ..
  make && sudo make install
in other words, a fairly standard procedure, for projects all around the net.
- Now what if you want i18n to go with that?
There seems to be no uniform answer to this for all (or even most) projects in 
KDE. Manually copying pos from svn and adjust CMakeLists for that may just 
work, if you are really familiar with KDE infrastructure. releaseme is a great 
way for extragear apps to (among other things) fetch translations, but - as 
the name is already indicating - is quite obviously _not_ targetted at casual 
curious bystanders: It is a rather complex additional step for users to take - 
unless of course they are already knee-deep into KDE repos - it takes several 
minutes just to fetch the translations of a single catalog, it produces a lot 
of noise along the way, it does not give you an easy way to keep tracking 
after the initial "clone", ...
All of these are non-issues for the actual use-case of releaseme: Creating 
releases. But it's just not targetted at tracking development.

2. Why _is_ this a problem?
Well, workflows differ, but in my personal experience, having at least some 
users, who follow your development very closely, is a really, really wonderful 
thing to have. Receiving a bug-report on the day after you broke something 
makes bughunting _so_ much easier in some cases. Same goes for feedback on new 
features.
Now, only a small percentage of your users will ever follow this path, esp. 
for their day-to-day work. But some _do_ - if you make it easy enough. And 
that is absolutely worth going the extra mile, for - such as making sure they 
can easily work in their native language.

3. A small digression which will make me sound like a Canonical fanboy:
In fact, making source builds easy can be taken one step further, by providing 
daily builds. And whatever else you may think of them, launchpad has really 
hit the nail on the head on how to make this easy: All you need is a source 
repo, and debian packaging rules. They will pull your changes, do the builds 
as needed, do them for whichever Ubuntu releases you can support (making it 
really easy to produce builds that users can actually _use on their production 
systems_), and distribute them for you. (I do know Jenkins, and that's 
wonderful, too, but it just doesn't quite cover the same use case: Bringing 
your latest development to real users).
But of course the gotchas are still similar: This is only for users willing to 
risk running into or latest and latest bugs along with the features. That 
number is always limited, and going down, further, if you can't make 
translations come with that.

4. Solutions that just won't fly (unless stuffed in an airplane):
- You can include a copy of translations in your repo. Albert points out, why 
this is not a good idea, here:
  http://lists.kde.org/?l=kde-i18n-doc&m=141634372315940&w=2
- You can utilize releaseme to create dailies. But that requires an extra 
server to prepare the tarballs, does not easily fit into launchpad dailies, 
and does not help at all with "regular" builds from git.
- You can include a custom script to mimick the relevant steps of releaseme, 
for git-users to run. But that clearly increases the maintainance burden, does 
not help with launchpad dailies (or other build recipes for git versions), 
will still take a long time, will still produce a lot of noise...

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?

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

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