Re: Proposal for declinations in gettext

[Danilo Segan <dsegan gmx net>]

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