Glade-3 in packs?

Djihed Afifi djihedlists at googlemail.com
Wed Nov 28 09:03:17 UTC 2007


Hi Danilo,

Thanks for the explanations.

But I think you lost me there in semantics.


> 
> It's not our decision: it's a technically hard problem.  The only
> assumption we make is that packages will contain proper POT and PO
> files.  If that doesn't happen, it's easier to fix it in a package,
> than to try to construct a reasonable POT from all the PO files
> (i.e. you may end up with too many messages for translation which are
> obsolete, thus making translators do unneeded work, you may have
> conflicting messages in different PO files, etc).

What's technically hard about compiling existing .po files from
upstream?
You don't need the original .pot files for that.

> 
> No, but I probably miss your point.  What they, however, do lose is
> the ability to get updates with future language pack updates (the plan
> for Gutsy is to issue them monthly). 

I meant - Since Launchpad and the language packs can't get the glade-3
catalog* - or any other package which can't build them, just roll the
translations with the package itself. 

Scheduling them for language packs and then not providing them at all is
a mistake. If at a later stage this is remedied, both a language pack
and a glade-3 pack should be reprovided to avoid conflicts.

* (now it is thankfully fixed)

>  Ubuntu is so far the best
> distribution when it comes to propagating translator work to their
> users (imo, though there's a lot to improve still), and that's solely
> due to Launchpad/Ubuntu

No, it isn't. It's not better than a distribution that just rolls
everything with their original packages, and does no language packs.

Sure that option may have drawbacks like bandwidth, but omitting whole
existing translations is not one of them.

<I'm an ubuntu user btw>

> 
> > Not the right decision I believe.
> 
> It's technically very hard to do anything else properly.

Again, what's technically hard about rolling translations with their
original package?

> 
> Anyway, this is not because of Launchpad, this is because we're
> providing language packs for Ubuntu, and want to make sure that some
> data is at least correct.  Launchpad itself works for much more than
> just intltool-enabled modules, so it can't regenerate POT files in the
> way damned-lies (on l10n.gnome.org) does.

Either way, it is because of the bureuacracy in the middle. Bureaucracy
can't handle them? just roll it the old fashioned way!

(I'm repeating myself here)

> 
> And, fwiw, this might as well be broken behaviour in upstream Glade3:
> i.e. standard intltool build rules always create a POT file and put it
> in a tarball.  There's a lot of sense in that, and not least of them:
> how would you start translating a package if it comes with no POT?

If I am an end-user, I don't want to translate a package, my priority is
to get it. If I decide to translate a package, well in the case of
Glade-3, I do as I did and go spend hours on the upstream package to
translate it.

And then sit and wait for ubuntu to deliver them and wonder where my
work has gone. 

Djihed


-- 
Have a project you would like to be translated to Arabic?
Let us know:
http://wiki.arabeyes.org/Translation_requests

Blog: http://djihed.com





More information about the ubuntu-translators mailing list