Q_()

[Egmont Koblinger <egmont uhulinux hu>]

Hi,

There's been a discussion here a few months ago how to make the same English
text translated differently in different contexts. It was important e.g. for
the texts of the bottom bar whose translations have to fit in 6 characters.

It seems to me that this wasn't fully implemented. E.g. there's only one
'msgid "Search"' string in the .pot file. This is displayed at more places,
e.g. for F7 in the viewer's bottom bar, as well as in the title of the
dialogue window brought up by pressing F7. Currently the Hungarian
translation is "Keresés" which is "Search" as a noun. This doesn't fit in
its cell on the bottom row, so it looks stupid. Another possibility is to
use the word "Keres" which is a verb ("he searches") which fits the given
field but sounds a little bit sillier. The perfect solution would be to use
"Keres" in the button bar due to the size limit, but "Keresés" in the
dialogue window title.

I don't know how that thread ended and I cannot find it now, but I found the
Q_() and g_strip_context() functions in glib (what already we use anyway) so
it seems to me that they're the best (and most standard) choice we could
stick to.

Their description is here:
http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html

So basically the following could be used in mc's source:
  x = Q_("bottombar|Search");
  y = Q_("verb|Search");
  z = Q_("noun|Search");
  etc...

and .po files could look like this:
  msgid "bottombar|Search"
  msgstr "Keres"

  msgid "noun|Search"
  msgstr "Keresés"
  ...

Q_() calls g_strip_context() so it takes care to remove the text up to the
first "|" character if the string is not yet translated (the translation is
the same original string.) However, g_strip_context() should manually be
called on N_()-like strings.


These functions/macros are only available from glib 2.4, so currently we
would need to test for their presence and use an own implementation if older
glib is being used, but this shouldn't be a problem, as implementing these
functions is a trivial job, and as we know it from the flames of last week,
there are some autoconf gurus also who can implement autodetection. :-)

I think that using such a standard interface (even if it's a new one and we
need temporary hacks to support older glib) is a perfect way to go, and will
be even much better if one day in the far-far future we can drop support for
glib < 2.4.

If you like this idea, I can send patch to mc to introduce this feature,
except for the autoconf part. But maybe autoconf magic isn't needed at all,
since Q_() is a macro, a simple #ifdef Q_ will do it in mc's source.



-- 
Egmont