Pidgin is string frozen!

[Mark Doliner]

On Sun, Jan 30, 2011 at 11:56 AM, Mișu Moldovan <dumol at gnome.org> wrote:
> I've just
> discovered that there are a number of strings with accelerators in
> Pidgin's interface which have no accelerators in the POT/PO files. They
> all have an accelerator on the first letter and it seems as if this
> accelerator has not been marked for translation in the original string.
>
> Here's what I've identified so far:
*list trimmed*
> msgid "Allow plaintext auth over unencrypted streams"
*list trimmed*
>
> ...but they could be more, I haven't checked all protocols. All of them
> are from the „Advanced” tab of the "Modify account" window, which is
> protocol specific. The problem is that sometimes accelerators overlap
> in the Romanian localized version of this tab and I can't change that!
>
> Is this a bug or I'm just clueless?

You're not clueless--this is actually intentional.  The code in Pidgin
that displays these strings automatically prepends an underscore to
the beginning of the translated version of the string, so that the
first letter is automatically set as the accelerator key.

Why do we do this, you ask?  The strings in question come from the
libpurple source code.  libpurple is our UI agnostic backend library
responsible for connecting to the various IM networks.  Using an
underscore to signify an accelerator key is a GTK-specific nuance.
Other UIs, like Finch and Adium, must strip this underscore from the
string before displaying it, which is a little cumbersome for them.

I think there are other strings in libpurple which DO contain an
underscore and which non-GTK UIs already have to strip out.  We should
probably be consistent, and I think it'd be better to include the
underscores in these strings.  Pidgin can happily use them and other
UIs can either strip them or possibly replace them with some other
special markup for whatever UI toolkit they use to render the strings.

Having overlapping accelerator keys is a relatively minor problem, and
if we change this behavior now then we kind of break compatibility
with existing UIs (not API compatibility... but it does break their
expectations of libpurple).  I think this is something we should
probably change for 3.0.0.

--Mark