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

Hi,

On Thursday 27 November 2014 19:49:51 Albert Astals Cid wrote:
> > On Thursday 27 November 2014 00:22:40 Albert Astals Cid wrote:
> > > Sincerely, i don't see ourselves having yet another copy of the
> > > translations in another part of SVN.
> >=20
> > ok, point taken. But again, the exact place of storage is not actua=
lly the
> > central part of my suggestion.
>=20
> Then i am not sure i understood your suggestion :/

well, the point is not _where_ to store translations, but in what form.=
 In SVN=20
they are stored in a form that is great for translators, organized by:
   language - type (doc, data, message) - section - project
What I want is a project-centric "export", organized by:
   project - type - language
The point is that from this export I can trivially slice out everything=
 that=20
is relevant to my project.

I think there is no disagreement that at _some_ point projects (where p=
roject=20
=3D=3D something to be released individually) will need that kind of se=
tup. The=20
really obvious point is at release time. And releaseme covers this use =
case=20
"making a release", nicely.

I'm arguing it would be useful to have this continually, to cover the u=
se=20
cases of dailys, and repo builds. releaseme is pretty clunky for that p=
urpose.=20
So to help that, I would like to see translations "exported" in a proje=
ct-
centric "view" (for projects that want this).

> That's what i want too, if projects need daily tarballs, we can make =
a way
> for a sysadmin bot to generate them with releaseme and put them on
> download.kde.org, that is not a solution specific to your project, it=
's only
> that it seems your project is the one that needs it at the moment :)

Hey, I would not mind an easy way to get daily tarballs, either, as you=
 can=20
surely do a lot of interesting stuff with that. Including daily builds =
in=20
_some_ build systems. But then tarballs may be taking the processing a =
bit to=20
far, as that leaves behind:
=2D automated or semi-automated builds pulling their sources from repos
=2D users and developers working with the git sources

> I think the think is that you see it as a single product, i see it as=
 a
> different product. One thing is RKWard, and another is the german
> translation of RKWard, sure they are related, but so is the webpage o=
f
> RKWard and you don't expect them to find it in the same tarball. So w=
hat we
> expect is that people interested in the RKWard product install it, if=
 then
> they are interested in the "addon product" "RKWard german translation=
" they
> go and install it.

I'll bite: But then I'd still want a good way to ship that "addon" "RKW=
ard=20
german translation (bleeding edge)".

Sure, bundling all translations with one product is not the only way to=
 go.=20
For large and tightly coupled bundles, bundling one language for many p=
roducts=20
is a great alternative. Not really for the more individualistic, extrag=
ear=20
projects. And I don't think you'll seriously argue otherwise. Even less=
, when=20
we're talking about tracking bleeding edge development for a specific p=
roject.

Yes, again, you're pointing to a viable solution for _one_ of my usecas=
es: For=20
a single user following git, it would be perfectly enough to get "their=
"=20
translation, and that would be an easier task to accomplish than fetchi=
ng all=20
translations (but not a trivial task, either, if we're talking about se=
veral=20
docbooks, and several message catalogs; in that context I might have to=
 point=20
out that RKWard is about to see a small explosion in the number of its =
message=20
catalogs: on the order of 7 or 8, probably).

But again, it would not cover the other usecase: Easier dailies (in cer=
tain=20
build systems), without prior knowledge of the users' language preferen=
ce. But=20
both can be covered in a straight-forward manner, IMO.
=20
> There's never been a pressure for people building from source without=
 any
> script (afaik kdesrc-build let's you specify you want translations an=
d will
> take care of it) to make things easier, because at that point it beco=
mes a
> script and you may as well use kdesrc-build.

I think we're straying from the main points, here. But in short:

=2D kdesrc-build seems somewhat orthogonal to this discussion to me. Givi=
ng it=20
only a cursory glance, it seems rather targetted at solving the (depend=
ency)=20
problem of getting the latest of a KDE app that requires the lattest of=
 KDE=20
library X, that requires the latest of ... We're not playing in that le=
ague.=20
Actually our user base tends to be quite conservative about their insta=
lled=20
libraries.
=2D Just because users who dare to venture some way don't complain, does =
not=20
mean you can't get more users to venture that way, if you make it more=20=

comfortable. If you actively want users to follow you on git, you'd bet=
ter=20
make it as easy as possible, with as few drawbacks as possible.
=2D Similarly, just because users are not asking for a translation in=20
development buils, does not mean they wouldn't like to see one, or that=
 you=20
wouldn't be able to attract more and different users by providing one.
=2D If my suggestion gets real, getting translations is going to be a tri=
vial=20
operation, from the perspective of a user, from the perspective of a=20=

developer, and from the perspective of many build recipes. Long way to =
go,=20
before it will look scarier than reading up on kdesrc-build (or any oth=
er tool=20
you've never heard of before, outside of KDE-land).

> I'm not a kdesrc-build expert, but maybe for your "people that build =
from=20
> source and need translations" all you need to do is provide in your w=
eb a=20
> sample kdesrc-build rc file that does that?

Actually, (to a large, but not exclusive part), I'm talking about peopl=
e who=20
experiment with building from source, and did not even realize that cou=
ld mean=20
any problem WRT translations - but after trying it they just find it wo=
rks=20
remarkably well.

Regards
Thomas
--nextPart2826847.kmzJNKr2XR
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

iEYEABECAAYFAlR3mc0ACgkQEKRv+5DVNhhg6ACgo3Qc9Bx3VwKRbiwr9UM/pHbb
xa0An2HTQVwd8UEuEtrUWXxrGPNv3WgK
=HtNS
-----END PGP SIGNATURE-----

--nextPart2826847.kmzJNKr2XR--