feature request for gettext (gnumeric: Note to translators)



2001-02-12T15:29:33+0100, Pablo Saratxaga ->
> > Other things I've had problems with is programs that use the same string
> > for menu labels as for toolbutton labels. If the english string is short
> > it works for them, but if the translation is long then the toolbutton
> > becomes big. If you translate to a abbrivation, then the toolbutton is
> > nice but the menu is ugly.
> 
> Such cases must be made known, so the sources are changed to allow
> distinguishing them.

The general solution to this problem would be to fix the gettext
function, so that you can write for instance:

msgstr "#context#string"

I don't care how the syntax is, but it should be something that is not
likely to cause breakage of old .po-files.

Then this problem will be gone forever. When a translator finds a string
which is used on two places in different contexts, he simply changes the
strings in the source to "#context1#string" and "#context2#string".
Also programmers can specify context, even if there is no conflict, to
make translation easier.

The translator can choose to include the "#...#" or to exclude it.

msgstr "#math function#mean"
msgid "medelvärde"

The problem with doing this is that you cant just #define _() if you
don't want gettext. But i think it's a small price to pay.

You can even use old gettext implementations, just make sure that _()
has some wrapper code which removes #...# if first in the string.

Another question is plurals, which is implemented by ngettext, but I
still haven't seen any implementation of msgfmt, gettext, or msgmerge
for it.

	n.

-- 
[ http://www.dtek.chalmers.se/~d95mback/ ] [ PGP: 0x453504F1 ] [ UIN: 4439498 ]
    Opinions expressed above are mine, and not those of my future employees.
SIGBORE: Signature boring error, core dumped




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]