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

List:       kde-i18n-doc
Subject:    Re: i18n setup for RKWard
From:       Thomas Friedrichsmeier <thomas.friedrichsmeier () ruhr-uni-bochum ! de>
Date:       2014-11-18 21:51:00
Message-ID: 1760158.sFXxIesJmQ () late
[Download RAW message or body]


Hi,

On Tuesday 18 November 2014 21:48:20 Albert Astals Cid wrote:
> Having a copy of the translations is bad for several reasons:
>  * People won't know where to commit, and it will create conflicts once one
> persoon commits to the wrong place

hm, I dare say that's not going to be a real world problem while the repo is 
hosted on kde.org? Of course for further signalling the nature of the .po 
files inside the repo, there is no longer a .pot-file coming with them (since 
today), and of course there is a README.translations next to the .po files 
(since ages).

>  * Creates extra noise in your repo (and potentially makes merging between
> branches harder)

True (at least for the part about the noise; merge problems in this area seem 
like a rather hypothetical problem to me). OTOH it also allows to tag the 
exact state of translations along with a release, easily.

> Also your reason is a good one (you want to include translations in a daily
> build) but you don't realize that you're making translations a second
> citizen compared to the code because you will make daily builds with
> updated code but potentially outdated translations.

True, if and only if I can actually get those dailies to build with 
translations at all.

> So if you have a server (i guess) that does this daily builds what you
> should make it is mae sure it runs a script that fetches the updated
> translations from the proper place (running releaseme sounds like a good
> idea) and from there carry on with the daily build.

Well, we're using "public" infrastructure, here, not own servers. For the 
Ubuntu dailies (currently two variants cross five Ubuntu releases) that's 
launchpad PPAs. These essentially build the current repo using the debian 
rules we already have. I don't think it's even possible to add logic to 
download translations from somewhere, in debian rules. AFAIK it is possible to 
merge some bzr-branches on launchpad to form a repo+translations set, but I 
can't really think of a way to do this in a way that does not require any 
manual intervention (at least to prepare and update the bzr branch holding the 
translations).

The macports ports are
a) built on the macports buildbots
b) still one of the easiest ways to build on Mac.
These are not even dailies, but using references to certain commits, rather 
than release tarballs makes it very easy to also allow building development 
snapshots. I believe it is _likely_ possible to fetch additional parts to be 
inserted in the source tree, in a portfile. Although it would make the 
portfiles more complex, and I could quite imagine some policy going against 
this - as dealing with two independent parts of the source clearly raises some 
opportunities for interesting trouble.

Oh, and then there are some people manually building from the source repo the 
old-fashioned way. For those, I'd need integrate translation-fetching into the 
build-process, somehow.

So I can see your points, but I'm not quite convinced. At least not to the 
point of putting any significant amount of effort into solving the above 
issues, at this moment.

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

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