Re: "Apparent" string-freeze breaks in gok, gnopernicus
- From: Christian Rose <menthos gnome org>
- To: Danilo Šegan <danilo gnome org>
- Cc: GNOME I18N List <gnome-i18n gnome org>, Kjartan Maraas <kmaraas gnome org>, GNOME Release Team <release-team gnome org>
- Subject: Re: "Apparent" string-freeze breaks in gok, gnopernicus
- Date: Sun, 12 Sep 2004 19:05:52 +0200
sön 2004-09-12 klockan 10.25 skrev Danilo Šegan:
> Hi translators,
> There have been apparent string freeze breakages in gok and
> gnopernicus, according to status pages.
> Still, these are not string freeze breakages, but rather,
> intltool-extract bugs fixed (without me even knowing about these
> bugs really existing in any of the real Gnome modules!). This is part
> of the relevant ChangeLog entry I added at the time:
> * intltool-extract.in.in (type_xml): Adjust re to allow for
> translating both content and attributes (i.e.
> <_t _name="ah">content</_t>).
> It was part of the fix at
> So, the problem was that intltool never allowed translatable tags to
> have attributes as well, which is what GOK and Gnopernicus have been
> using for quite some time.
> Now, I guess Carlos has just updated intltool to latest CVS HEAD on
> the computer which generates status pages, and that's why this has
> shown this late in the process. Carlos, can you confirm or deny
> this guess of mine?
> Since this still seems like a string freeze break from translators'
> POV, I'd like to hear some comments on the any of the following
> 1. leave everything as is, meaning translators have a bunch of
> messages to translate this LATE in the process
> 2. get back to earlier intltool for status pages, thus making
> translations stay at the same status as they were, but advise gok
> and gnopernicus maintainers to use latest CVS HEAD intltool so
> those translations which exist would be used (translators would
> have to check-out gok/gnopernicus and use latest intltool if they
> wish to have these translated)
> I'm terribly sorry that intltool is as buggy as it is, but I at least
> hope that I'm doing a good job in reducing the number of those bugs.
> The solution would probably be to switch intltool-extract to XML
> parser as well, but with bad choice of XML parser (IMO) for
> intltool-merge, we'd lose ability to have comments extracted, etc.
> It's also a shame GOK and Gnopernicus users haven't noticed this any
> earlier (that these messages weren't translated).
Danilo, please always cc: the release team on string freeze issues.
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
But I'm probably leaning towards that intltool should be fixed. But I'd
like to hear the other opinions above aswell.
] [Thread Prev