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

List:       kde-i18n-doc
Subject:    Re: i18n setup for RKWard
From:       Albert Astals Cid <aacid () kde ! org>
Date:       2014-11-18 22:31:12
Message-ID: 8435445.CFAvZrl5OU () xps
[Download RAW message or body]


El Dimarts, 18 de novembre de 2014, a les 22:51:00, Thomas Friedrichsmeier va 
escriure:
> 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? 

Why not? You're different, so people will assume that since you're different 
they may have to act different.

> 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.

That's up to you, but note you're acting different than everybody else against 
the recomendation of the group.

Cheers,
  Albert

> 
> Regards
> Thoams

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

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