_X-XfceSettingsName not getting 'expanded' with translations in .desktop files

[Alexander Toresson]

On Sat, Oct 18, 2008 at 12:11 PM, Enrico Tröger <enrico.troeger at uvena.de> wrote:
> On Sat, 18 Oct 2008 12:05:16 +0200, "Alexander Toresson"
> <alexander.toresson at gmail.com> wrote:
>
>>On Sat, Oct 18, 2008 at 3:46 AM, Brian J. Tarricone
>><bjt23 at cornell.edu> wrote:
>>> On Fri, 17 Oct 2008 23:48:44 +0200 Alexander Toresson wrote:
>>>
>>>> On Tue, Oct 14, 2008 at 11:23 PM, Brian J. Tarricone
>>>> <bjt23 at cornell.edu> wrote:
>>>> > Brian J. Tarricone wrote:
>>>> >> Alexander Toresson wrote:
>>>> >>> On Tue, Oct 14, 2008 at 11:11 PM, Brian J. Tarricone
>>>> >>> <bjt23 at cornell.edu> wrote:
>>>> >>>> Alexander Toresson wrote:
>>>> >>>>> Hello,
>>>> >>>>>
>>>> >>>>> I just noticed that _X-XfceSettingsName won't get expanded to
>>>> >>>>> X-XfceSettingsName[LANGCODE] in trunk and thus translations of
>>>> >>>>> the entries in the settings manager fall back to using
>>>> >>>>> _GenericName, and are thus needlessly long.
>>>> >>>>>
>>>> >>>>> I also took a look at how .desktop files are generated from
>>>> >>>>> .desktop.in files, and as the process does seem to be done by
>>>> >>>>> intltool (by invoking @INTLTOOL_DESKTOP_RULE@), is this a bug
>>>> >>>>> in intltool?
>>>> >>>> Yes, you have a buggy intltool.  Either upgrade to intltool
>>>> >>>> 0.40.4, or use a 0.3x.y version of intltool, and
>>>> >>>> xfce4-dev-tools will patch it for you during autogen (at least
>>>> >>>> it will try -- watch the output; if it fails, you're out of
>>>> >>>> luck).
>>>> >>> Ah, yeah. I get the following during autogen:
>>>> >>>
>>>> >>> WARNING: Unable to patch intltool-merge from versions 0.40.0
>>>> >>> through 0.40.3. WARNING: Generated .desktop files may be
>>>> >>> invalid. WARNING: Unable to patch intltool-merge from versions
>>>> >>> 0.40.0 through 0.40.3. WARNING: Generated .desktop files may be
>>>> >>> invalid.
>>>> >>>
>>>> >>> I will try to figure out why it fails tomorrow. Perhaps it
>>>> >>> conflicts with a distro-specific patch to the same file.
>>>> >>
>>>> >> No, it CANNOT patch 0.40.0 - 0.40.3, ever.  You are SOL if you
>>>> >> use these versions.  Your only options are 0.40.4+, or a 0.3x.y
>>>> >> version that just happens to get patched properly by trial and
>>>> >> error.  As I said.
>>>> >
>>>> > Well, ok, that's not entirely true -- you can manually patch your
>>>> > /usr/bin/intltool-merge.  Our autogen script can't do that for
>>>> > you, for obvious reasons.
>>>> >
>>>> >        -brian
>>>>
>>>> If I understand the patching process correctly, it works for 0.3x.y
>>>> because those versions expose a intltool-merge.in in the build
>>>> directory, and this is why the same process doesn't work for 0.40.x,
>>>> because it doesn't?
>>>> Would it be feasible/'nice enough' to, for 0.40.x, install a patched
>>>> intltool-merge script with a different name (xdt-intltool-merge?)
>>>> when installing xfce4-dev-tools, and then make the Makefiles use it
>>>> instead of intltool-merge?
>>>
>>> Feasible, but I don't want to do this.  Distros with 0.40.0-3 should
>>> be pushed to update to 0.40.4.  People rolling their own packages
>>> should do the same.
>>>
>>
>>My main personal concern at the time is that Debian Lenny runs a risk
>>of being released with intltool 0.40.0.
>>If that happens, I volunteer to create a patch that does the above.
>
> I'd suggest to try to get this fixed in Debian first.
> File a bugreport for Debian's intltool package and make it an RC bug,
> then someone will have a look and in the best case accept a patch, in
> the worst case he'll deny it but then you have tried it at least.
>

That's exactly what I'm trying, I filed #502561 last night. Except the
part about marking it as an RC bug; I see no reason for that. The
response I have received so far is good, though.

// Alexander