Re: Proposal for declinations in gettext

[Miloslav Trmac <mitr volny cz>]

Hello,
On Sat, Jun 14, 2003 at 08:29:43AM +0200, Danilo Segan wrote:
> #: libnautilus-private/nautilus-search-uri.c:325
> msgid "[Items ]modified today"
> msgstr "modified today"
> 
> The problem here is that in Serbian (I did the Nautilus translation, so 
> I know what I'm talking about :-)), the correct (or at least a way 
> better) form would be "Today modified items", instead of "Items modified 
> today". Or, it could also be "Items that are modified today", which 
> doesn't follow the pattern, and should be composed like some other 
> strings ("[Items that are ]named[ README]"). If a translator would 
> translate it as "that are modified today", it might work for this 
> particular example, but it might be used in inappropriate ways (s)he 
> doesn't know about.
If I understand it correctly, these strings are used to "build"
search query GUI. That means that there is the "Items" option menu
on the left and the "condition" option menu on the right of it.
This GUI style just doesn't allow keeping the correct word order
in some cases, especially if you want to do boolean queries.
printf () doesn't enter the picture here.

> Approach with 
> [context] markers instead of format strings might work for many 
> languages, but it wouldn't work for all -- actually, it would be wrong 
> in some. So, I believe this kind of context information belongs in 
> comments-to-translators, which xgettext also extracts without problems.
I think we'll both agree that the main problem is stitching strings
together from multiple pieces, which should be avoided if possible
(especially if it is known it causes problems).

The context markers don't solve only the "providing context for
translators", they also solve msgid uniqueness.
"January", "February", "May", ...
"Must", "May", "Must not"

Quite a few programs need to solve similar problems and this was the main
reason I'd like to see a standard way included in gettext
(gettext_stripcontext () ?).

> What my approach is to solve, is that once context information is 
> available (whether a translator ran the program in question, and 
> discovered how some strings are composed "incorrectly", or the 
> programmer provided that kind of information on composition), translator 
> has the possibility to make it work for his own language. So, you 
> provide declinations only when you know they're needed.
Is there a way to find out which declinations are needed for which
words (preferably a way not equivalent to solving the halting problem)?

How this would ultimately be implemented is associating a single "gettext
context" to two or three messages to pass the declination information.
This also means that gettext provides a *printf () replacement that
groks the declination syntax. Ultimately, I don't see that much
differenece from marking the context "inline".
	Mirek