KLocalizedString regression

John Tapsell johnflux at gmail.com
Fri Mar 25 21:56:07 GMT 2011

On 25 March 2011 21:42, Chusslove Illich <caslav.ilic at gmx.net> wrote:
>> [: John Tapsell :]
>> Except that in my case, I'm forcing this on the users of my API. Just to
>> get around this!
>> Can't you see how crazy this is?
> An integer is mandatory to decide the plural form, a float cannot be used,
> due to the following. Suppose there are m plural forms for a given language.
> The plural call pushes the integer through a formula, defined by that
> language (by each PO file to be precise), which maps it to 0 through m - 1.
> If the plural call would get a float instead, how should it decide which of
> the m forms to map to? For example, in my language forms are 0 through 3,
> and the correct one for a floating value is 2 -- not 0, 1, or 3.
> On the implementation level, what happens now when you do not supply an
> integer, is that non-plural call is simply passed down to non-plural
> gettext() from libc. It is a fluke that for English it silently returns the
> plural, and not the singular string. For all I know, if the libc were built
> in develop/debug mode (I use distribution package), it could do something
> else.
> Therefore two independent KLocalizedString parameters are indeed necessary
> for the API, if you want to keep the integer/real alternation. Since it is
> about graph plotting, I suggest that you make the API such that the real-
> value string is mandatory, and the integer-value string optional. I.e. let
> the client choose if he wants alternation or not.

Thank you very much your explanation - it makes a lot more sense to me now :-)

> Furthermore, I would suggest that the axis tick labels be pure numbers, and
> the axis name and unit shown separate in one place, e.g:
>  ------------------------------------------>
>  0     1     2     3     4     5     6
>              time [seconds]

As an published engineer myself, I fully understand.  But there's a
few practical problems - we do not have much vertical space, for
example.  Putting on such an axis would pretty much halve the height
available for the graph itself.

If you were thinking of this for the vertical axis, then you are
either asking for vertical text, which is evil, or a huge amount of
wasted on the left hand side.


More information about the kde-core-devel mailing list