Re: "Apparent" string-freeze breaks in gok, gnopernicus
- From: danilo gnome org (Danilo Åegan)
- To: GNOME I18N List <gnome-i18n gnome org>
- Subject: Re: "Apparent" string-freeze breaks in gok, gnopernicus
- Date: Sun, 12 Sep 2004 21:14:28 +0200
Today at 19:56, Ãsmund SkjÃveland wrote:
>> 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?
> Change intltool half a day before GNOME 2.8 tarballs roll? You can't
> be serious.
Let me restate this perhaps more clearly: changing intltool won't
have any effect, except for the visibility effect we will get using
an older intltool for status pages.
Newer intltool won't break anything for translators, it will only add
some new strings â if they're already updating gok or gnopernicus
translations, perhaps it's even better if they do it completely (1
new message for GOK, ~20 for Gnopernicus, all of them being very
simple). If there is any translator who minds getting these messages
(if she translates them, they *WILL* be used), she can either use old
intltool, or grab PO file from status pages (once we get intltool
un-upgraded [degraded?] there).
We simply shouldn't count this toward completness â we need not
change intltool to achieve that.
Technically, all tarballs can use either of intltool 0.31.1 or
intltool 0.31.2, and they'll do fine. This switch touches only on
our *count* of translatable messages (if we ignore that some messages
will be untranslated if translator used 0.31.1). Because we didn't
acknowledge this bug soon enough, we should be nice to translators.
] [Thread Prev