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 -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/