Re: menu-patch-2

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj@gtk.org> writes:

> > It should handle 99% or so of the cases correctly. But it
> > seems a little odd to take the string where the translator
> > has put the underline where they want it, create an accelerator
> > from it, and have the AccelLabel try to guess where that 
> > accelerator is, when we could just easily create the pattern
> > with the ItemFactory to begin with...
> 
> that is correct. but then again, it wasn't my idea to put the accelerator
> information into the menu path. exactly the opposite is the case, i wanted
> to keep the menu paths clean and have the extra accelerator sit inside
> the *accelerator string of GtkItemFactoryEntry. with that kind of
> setup, it would have actually made sense for language bindings that
> want to translate accelerators as well. 

OK, I didn't understand this before - I still don't understand it...
maybe you could explain further.

A language binding that wants to translate (what does "translate"
mean here?) language bindings? 

(Are you saying that the language binding, since it isn't C,
needs to use something other than gettext? Well - they
also need to use something other than ItemFactory, or provide
a wrapper around it)

(I think you were inventing your own message catalog translation
system - I'm trying to figure out how to make things work
with gettext)

As for putting the underline accelerator in the accelerator string - I
think you understand now that underline accelerators aren't just the
same thing as normal accelerators - and that the same menu item
generally has _different_ accelerators and underline
accelerators. So...

The big advantage of sticking it in inside the menu path itself is
that the (human) translator gets the menu path when they are
translating the underscore, and, within the framework of gettext, that
is necessary to do the correct translation, and to handle cases where
the same string needs to be translated multiple ways.

Anyways, the question I have is, should I be worrying about this?
I don't really understand the objections you have here.

> but we got that now through your hackups with the path itself, and
> it works at least for installation.  

For installation? Accelerator installation? (The concept of
changing underline accelerators on the fly makes no sense to
me since they are active when the menu is active)

> also i even think this is the
> easier solution for the user side of the item factory, but we
> definitively need to substitute the '&'.  good candidates are '_'
> (didn't conzept-16 use that?) or '@' (IIRC, this was used by turbo
> vision) or maybe even '~'.

'_' probably is nicest. Though '&' is very standard, and we
could implement a '&&' escape to get '&' pretty easily.

                                        Owen