[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:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2014-11-27 21:38:17
Message-ID: 2357918.maMFs8t2XB () late
[Download RAW message or body]


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.
> > 
> > ok, point taken. But again, the exact place of storage is not actually the
> > central part of my suggestion.
> 
> Then i am not sure i understood your suggestion :/

well, the point is not _where_ to store translations, but in what form. In SVN 
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 
is relevant to my project.

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

I'm arguing it would be useful to have this continually, to cover the use 
cases of dailys, and repo builds. releaseme is pretty clunky for that purpose. 
So to help that, I would like to see translations "exported" in a project-
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 
surely do a lot of interesting stuff with that. Including daily builds in 
_some_ build systems. But then tarballs may be taking the processing a bit to 
far, as that leaves behind:
- automated or semi-automated builds pulling their sources from repos
- 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 of
> RKWard and you don't expect them to find it in the same tarball. So what 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" "RKWard 
german translation (bleeding edge)".

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

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

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

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

- kdesrc-build seems somewhat orthogonal to this discussion to me. Giving it 
only a cursory glance, it seems rather targetted at solving the (dependency) 
problem of getting the latest of a KDE app that requires the lattest of KDE 
library X, that requires the latest of ... We're not playing in that league. 
Actually our user base tends to be quite conservative about their installed 
libraries.
- Just because users who dare to venture some way don't complain, does not 
mean you can't get more users to venture that way, if you make it more 
comfortable. If you actively want users to follow you on git, you'd better 
make it as easy as possible, with as few drawbacks as possible.
- Similarly, just because users are not asking for a translation in 
development buils, does not mean they wouldn't like to see one, or that you 
wouldn't be able to attract more and different users by providing one.
- If my suggestion gets real, getting translations is going to be a trivial 
operation, from the perspective of a user, from the perspective of a 
developer, and from the perspective of many build recipes. Long way to go, 
before it will look scarier than reading up on kdesrc-build (or any other tool 
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 
> source and need translations" all you need to do is provide in your web a 
> sample kdesrc-build rc file that does that?

Actually, (to a large, but not exclusive part), I'm talking about people who 
experiment with building from source, and did not even realize that could mean 
any problem WRT translations - but after trying it they just find it works 
remarkably well.

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

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