Re: [PATCH] Gettext 0.19 errors; Workflow for irregular i18n contributors

[Piotr Drąg <piotrdrag gmail com>]

2014-06-14 16:15 GMT+02:00 scl <scl gplus gmail com>:
> On  14.6.2014 at 2:52 PM Piotr Drąg wrote:
> > First, it uses an out of date checkout of the GTK+ repository.
>
> Indeed my patch is based upon GTK 2.24.23 which is three months old.
> Sorry, it was my fault to not base my patch on HEAD. What a luck I
> didn't merge in the pot files.
> I just checked the log of the directories po and po-properties and
> their last changes are of 2013, so nothing has changed there since
> the 2.24.23 release. Or am I missing something?

I see, you want to fix the gtk-2-24 branch. I'm afraid it is low on
the list of priorities. Couldn't you build GIMP with gettext 0.18.x
until it's ported to GTK+3?

> > Most of these files already have the Language tag.
> Hmm, I added it only to those files where it was missing. Do you have
> an example where it's already included?

I was thinking of the master branch, actually. In gtk-2-24 only a
couple of po files have the tag, as you noticed. I'm not sure if it's
worth fixing at this point, but GTK+'s developers might have a
different opinion.

> > Second, it changes mode
> > (permissions) of all po files, which should be avoided.
>
> Sorry, this was my bad. I'll fix it.
>
>
> > Third, it
> > introduces format errors in these:
> >
> > po-properties/az.po
> > po-properties/crh.po
> > po-properties/ka.po
> > po/crh.po
> > po/ka.po
>
> I guess, you mean the trails of the "Language-Team" entries, that were
> continued on the next line, right? I'll fix this.
> Or do you mean some non-obvious encoding differences or something else?

Yes, I meant broken Language-Team headers.

> > Also, I think you should leave unrelated cleaning up of the headers up
> > to the teams.
>
> I considered this. On the other hand leaving a task to others
> in a volunteers' environment is quite unreliable. Also this task is not
> a challenging task people are keen on. Until the issue is completely
> fixed upstreams the patch will rot in our own repository.
> Therefore I'm rather doing it myself and offer my patch upstreams to be
> on the safe side and get the job done quickly.

Well, in my opinion it's just cosmetics, but I fixed it for you in the
master branch:

https://git.gnome.org/browse/gtk+/commit/?id=4406386ad9ed575efd280cc332c4b29f5517bdf1

> > Finally, it doesn't solve the problem with the hundreds
> > of other modules in GNOME.
>
> That's true and truly out of my scope. I'm only fixing the dependencies
> in the GIMP project that could cause us problems (and this is already
> more than one would expect or others would do).
>
>
> > It's important to learn the maintainer's opinion before pushing bigger
> > changes (I should know, I screwed gtk+'s POTFILES.in up in the past at
> > least once...).
>
> Yes, I understand that. Therefore I offered my patch here for discussion
> rather than pushing it blindly to the GTK+ repository.
>
> After all: I would fix the issues you mentioned and bring up an improved
> patch. Would that be ok?
>
> Kind regards,
>
> Sven

-- 
Piotr Drąg
http://raven.fedorapeople.org/