Re: Removing unwanted internationalization info

[Danilo Segan <danilo gnome org>]

Hi Christian,

ÐÑÑÐ Ñ 21:36, Christian Rose ÐÐÐÐÑÐ:

> The centuries old and documented way of properly disabling a translation
> from being used is to remove its entry in the ALL_LINGUAS line, instead
> of having to delete or rename actual translation files. Intltool doesn't
> support this convention, but instead insists that every po file that
> exists should have its translations merged, regardless of the
> ALL_LINGUAS setting.
>
> Why do you consider this intltool behavior not to be a bug? What is the
> benefit of intltool, unlike gettext, ignoring this setting?

It worked for manual, non-autoconf build setups.  Eg. it's enough that
you call "intltool-merge -d -u po app.desktop.in app.desktop" in your
plain and simple Makefile to build a .desktop file.

> I'm afraid I don't understand that. I don't see anyone benefitting from
> intltool being inconsistent with gettext in this area and ignoring this
> setting.

gettext is a set of tools independent of build system.  One can use
msgmerge, msgfmt easily without using autoconf.  We want to do the
same with intltool, so we must not depend on file such as
"../configure.in" existing (and as you know, this caused a lot of
problems for us in the recent past â you even reported a bug for this
to be fixed, I believe, so intltool could be used without autoconf).

> Also, a bug is when an application doesn't behave as perhaps expected.
> This misbehavior could be of any reason: a (previously unknown)
> accidental code error, but also a known problem where the fix is not
> implemented yet, or a problem difficult to fix. The reason *why* the bug
> exists is a totally orthogonal issue to whether *it is* a bug and should
> be reported.

Application (intltool) behaves exactly as expected â that's the core
point.  There's no "misbehavior", and as you can notice, there're
some advantages to this approach.  Perhaps we could file a RFE for 
intltool so that it first tries ALL_LINGUAS in ../configure.in or
../configure.ac, next checks in LINGUAS file (or vice versa), and only
if all of these fail, use every .po file.

> If it is a misbehavior it should be reported as a bug. *Then* one can
> discuss to what to do in order to solve it, and whether it would be
> simple or difficult.
>
> To me, it sounds like you're either claiming that this unexpected
> behavior is not a problem at all, or that you're claiming that since it
> may be difficult to fix we shouldn't even keep track of the problem and
> instead ignore it and forget it. Either way, I can't for my life figure
> out why.

You're wrong â I'm claiming it's not a bug because it's useful in
certain contexts, and because it's what original developer desired
while implementing the feature.

Cheers,
Danilo