Re: Proposal for declinations in gettext

[Danilo Segan]

Miloslav Trmac wrote:

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).
 

Yes, but I'll stress that sometimes it's not possible to convince 
programmers to follow this guideline.

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

I did realise that, but that's not the issue at hand. It's even 
customary in Gnome to use "/Menu/Name/Item" out of which is used only 
"Item", in order to differentiate between differing uses of one word. I 
think I also saw some code example in gettext.info that suggests the 
same approach.

Of course, standardized context markers would be only better, not worse. 
What troubles me is how is that going to help the issue of string 
composition?
I think the problem is because programmer doesn't know how many forms a 
word can take in any language, and that's the number of "context 
markers" (s)he would need. Or, I misunderstood something.

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 () ?).
 

Yes, it'd be nice thing to have, but for entirely different reasons :-) 
If it'd get integrated, it might as well be called with the default 
gettext() call.

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)?
 

This is translators job, no?

Or do you mean: is there a way to extract what strings are used to 
compose some strings? If so, I think the answer is no :-( Programming 
practices at this moment are such that it would require knowledge of 
much of the code. Again, this kind of work was usually delegated to 
programmer, and a requirement is imposed on him to write 
"translator-comments" (as in "here, we'll compose string out of...").


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".
 

What do you mean by "marking the context 'inline'"? If you can think of 
any better solution that would work in general case, all the better.

On the *printf() replacement -- ultimately yes, gettext would need to 
provide such a replacement. But, how does gettext already handle the 
order substitution of parameters in format specifiers (%1$s, %2$s,...)?

Cheers,
Danilo
--
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/