Re: "Apparent" string-freeze breaks in gok, gnopernicus

[danilo gnome org (Danilo Åegan)]

Today at 19:05, Christian Rose wrote:
>
> Danilo, please always cc: the release team on string freeze issues.

Ok, sorry about that.

> Personally, I'm not decided on what to do, besides cursing at intltool.
> I'd really like to hear the release team and intltool maintainer
> opinions on this. Would it be feasible to change intltool behavior this
> late in the game, and get a new intltool release out that translators
> can use?

Kenneth is intltool maintainer, but I don't think he's available.
Rodney is doing the releases for now. (Both CCed)

There's no sense in changing intltool not to extract these strings.
We can simply ask translators to use older intltool versions (0.31.1
for instance, which they're probably doing at this time, so we need
not ask them anything), and we need to use that version for status
pages.  I don't thing the other fix in intltool 0.31.2 touches any of
the core Gnome modules (it's related to po/Makevars parsing).

These strings already exist in .xml.in files, and they're going to
continue existing there, so if someone has already translated them, I
see no reason to hide them.  It's just like the stuff you sometime do
when you find a misspelled original message: you copy by hand this
message to a correct one, so you need not update your translation
when the bug is fixed.  The thing is that proposed new intltool
tarball would look very much like intltool 0.31.1.

Basically, later (0.31.2) intltool extracts all the same strings
earlier one does, plus some more. 

intltool-merge doesn't have any problems, so if these translations
exist, they're used no matter what (even with 0.31.1).

Cheers,
Danilo