--nextPart12543266.IpQnsNVSa9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

Hi!

As a short introduction, I'm from project RKWard. We're in the process =
of=20
migrating from SF.net to KDE, and we have only just arrived on git.kde.=
org,=20
last week. So forgive me, if I have not quite understood some things, y=
et, or=20
go into unneccessary lengths at some points.

1. Problem statement:
=2D 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 th=
e net.
=2D Now what if you want i18n to go with that?
There seems to be no uniform answer to this for all (or even most) proj=
ects in=20
KDE. Manually copying pos from svn and adjust CMakeLists for that may j=
ust=20
work, if you are really familiar with KDE infrastructure. releaseme is =
a great=20
way for extragear apps to (among other things) fetch translations, but =
=2D as=20
the name is already indicating - is quite obviously _not_ targetted at =
casual=20
curious bystanders: It is a rather complex additional step for users to=
 take -=20
unless of course they are already knee-deep into KDE repos - it takes s=
everal=20
minutes just to fetch the translations of a single catalog, it produces=
 a lot=20
of noise along the way, it does not give you an easy way to keep tracki=
ng=20
after the initial "clone", ...
All of these are non-issues for the actual use-case of releaseme: Creat=
ing=20
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=20
users, who follow your development very closely, is a really, really wo=
nderful=20
thing to have. Receiving a bug-report on the day after you broke someth=
ing=20
makes bughunting _so_ much easier in some cases. Same goes for feedback=
 on new=20
features.
Now, only a small percentage of your users will ever follow this path, =
esp.=20
for their day-to-day work. But some _do_ - if you make it easy enough. =
And=20
that is absolutely worth going the extra mile, for - such as making sur=
e they=20
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 pr=
oviding=20
daily builds. And whatever else you may think of them, launchpad has re=
ally=20
hit the nail on the head on how to make this easy: All you need is a so=
urce=20
repo, and debian packaging rules. They will pull your changes, do the b=
uilds=20
as needed, do them for whichever Ubuntu releases you can support (makin=
g it=20
really easy to produce builds that users can actually _use on their pro=
duction=20
systems_), and distribute them for you. (I do know Jenkins, and that's=20=

wonderful, too, but it just doesn't quite cover the same use case: Brin=
ging=20
your latest development to real users).
But of course the gotchas are still similar: This is only for users wil=
ling to=20
risk running into or latest and latest bugs along with the features. Th=
at=20
number is always limited, and going down, further, if you can't make=20=

translations come with that.

4. Solutions that just won't fly (unless stuffed in an airplane):
=2D You can include a copy of translations in your repo. Albert points ou=
t, why=20
this is not a good idea, here:
  http://lists.kde.org/?l=3Dkde-i18n-doc&m=3D141634372315940&w=3D2
=2D You can utilize releaseme to create dailies. But that requires an ext=
ra=20
server to prepare the tarballs, does not easily fit into launchpad dail=
ies,=20
and does not help at all with "regular" builds from git.
=2D You can include a custom script to mimick the relevant steps of relea=
seme,=20
for git-users to run. But that clearly increases the maintainance burde=
n, does=20
not help with launchpad dailies (or other build recipes for git version=
s),=20
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=20
some effort into implementing this, too, if you agree that it might be =
a good=20
idea:

=2D In SVN, create a new subfolder "export" under l10n-kde4 and l10n-kf5.=

=2D In this, interested projects could place a config file, like e.g.:
  rkwardrc
  [main]
  projectname=3Drkward
  projectpath=3Dplayground/edu
  doc_destination=3Ddoc/
  [po_globs][rkward*.po]
  destination=3Dpo/{PONAME}.{LANG}.po
  [po_globs][if_you_really_need_this_too.po]
  destination=3Delsewhere/{PONAME}.{LANG}.po
  [doc_globs][*.docbook]
  destination=3Ddoc/{LANG}/{DOCNAME}.docbook
=2D Scripty will parse this rc file, and copy stuff to subdirectories of=20=

"projectname":
  rkward/po/rkward.de.po
  rkward/po/rkward.fr.po
  rkward/doc/en_US/index.docbook
  ...
=2D Of course, scripty will also do postprocessing similar to releaseme.=20=

Importantly, stripping stale messages form translations. Also, it shoul=
d=20
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 reduc=
e the=20
additional noise: Mere changes in line numbers would not cause an extra=
=20
commit.
=2D Projects can supply their own CMakeLists.txt, and place them where=20=

appropriate. Of course this could also be handled in analogy to what re=
leaseme=20
does. For a first sketch, we'll keep it simple.
=2D Similarly, projects would be responsible for cleaning stale docs and=20=

catalogs, for now. Scripty would only add (and overwrite) things.

6. So why would this help?
=2D Fetching l10n, and merging it into a source tree would become a rathe=
r=20
trivial operation: A single "svn export / co / up" is needed to get all=
 that,=20
and should be a matter of seconds in most cases. This makes it easy to=20=

document, and could even be integrated into a project's build system wi=
th just=20
a few lines of code.
=2D Works out of the box with launchpad, making it really, really easy to=
=20
provide dailies with the latest in code _and_ translations. And should =
be=20
similarly easy to build into most other systems that support repository=
=2Dbased=20
builds.
=2D Makes it easy to see just what will be added to the sources, instead =
of=20
looking like black magic to the non-initiated.

7. What does it not help with?
=2D Will not "push" updated translations to the user / build system by it=
self.=20
Only makes it easy to fetch them.
=2D Adds yet some more noise to SVN. Although that should be quite limite=
d in=20
comparison, if the file context info is stripped as suggested.
=2D All logic currently in releaseme will have to stay in releaseme (unle=
ss and=20
until all projects use this method for i18n).
=2D More work to do for scripty. However, overall ressource strain should=
 not=20
increase, and might even decrease, assuming any projects requesting exp=
orts=20
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=20
suggestion?

Regards
Thomas
--nextPart12543266.IpQnsNVSa9
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

iEYEABECAAYFAlR10RUACgkQEKRv+5DVNhirqQCginy8c3PQUflIwM3vNhQeLfpP
F9gAn1B82wBf69LHmobBCMrKEzBJal5U
=zNMg
-----END PGP SIGNATURE-----

--nextPart12543266.IpQnsNVSa9--