[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-27 18:49:51
Message-ID: 1803729.KR2oRF77FF () xps
[Download RAW message or body]


El Dijous, 27 de novembre de 2014, a les 09:06:37, Thomas Friedrichsmeier va 
escriure:
> Hi,
> 
> 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 :/

> 
> > Other option is just asking sysadmin to run releaseme nightly on some
> > server and storing it in ftp.kde.org.
> 
> Yes, true. I can come up with a bunch of other solutions that will extract
> messages for project rkward only, and store these whereever. And in fact, to
> cover my usecases(*), I _will_ have to do that.
> 
> This can be based on releaseme, but quite obviously it's not releaseme
> out-of- the-box, either. So - I will have to put some work into this.
> Coming up with a solution that is generic enough for other projects to use,
> too, does not seem much harder. And so that's why I'm writing lengthy
> mails, exploring if the idea resounds.

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 :)

> 
> Well, so far it does not. So let me try to make the point one final time:
> 
> I am certainly not the most seasoned venturer of the KDE codebase, but I
> have compiled a couple project from git. And I'll admit, in none of these
> cases, I have cared too deeply about translations. Although I'm not a
> native speaker, my desktop is running in English. So much more consistent
> when working with development stuff, in the first place (or is that
> actually just another symptom of the problem)?
> 
> So, apologies, for attempting proof by ignorance, but:
> I cannot remember stumbling over instructions on how to get i18n for a git
> build of a specific project _once_. Neither do I recall any instance of
> cmake telling me: "Configuration done, but, hey, there's no po-subdir
> around. Consider fetching it like so, in case you want translations." Do
> you(**)?
> 
> Why is that so?
> I can see two reasons:
> - Because other developer folks are like me, and just don't care enough (in
> particular, one could argue in an environment, where i18n - from the point
> of the developer, is something that "just happens", if you follow some few
> easy rules).
> - Because coupling development builds with translations is actually not an
> easy and straightforward thing to do in the current setup.

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.

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'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?

Cheers,
  Albert


> 
> It might be possible to improve on the second point, rather easily.
> 
> Regards
> Thomas
> 
> (*): And yes, the launchpad dailies are _really_ important to our project.
> build.opensuse.org would be a useful addition to, not replacement for that.
> BTW, the main obstacle to doing dailies, on opensuse, is that last time I
> looked, it needed sources to be pushed, there, instead of pulling changes,
> automatically.
> (**): Should the answer be yes, I'll definitely be interested in stealing
> some concepts, there.

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

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