KLocalizedString regression

2011-03-25 Thread John Tapsell
Hi all,

 ki18ncp(Units, %1 second, %1 seconds).subs(1.1, 0, 'f', 1).toString()

used to work  (return 1.1 seconds)  but now it returns (1.1
seconds(I18N_PLURAL_ARGUMENT_MISSING))  which screws up my graphing
widget.

This causes my unit tests to fail.

Can someone fix this pretty please?  I can't work around this.

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 12:45, Chusslove Illich caslav.i...@gmx.net wrote:
 [: John Tapsel :]
   ki18ncp(Units, %1 second, %1 seconds).subs(1.1, 0, 'f', 1).toString()

 used to work (return 1.1 seconds) but now it returns (1.1
 seconds(I18N_PLURAL_ARGUMENT_MISSING)) which screws up my graphing
 widget.

 This is the way it (should have) always worked. The plural call expects to
 get an integer, and if does not, it shows this warning (in debug build, not
 in release build).

That's not good :-(

If the number is small, I want to show   2 seconds   but if it's
large I want like 2.2e4 seconds.

You're saying that my API needs to require the user to now pass *two*
strings for that?

 On the language level, plural declination kicks in only on integer values,
 while real values always get plural form. This seems to hold for all
 languages currently known in KDE. In English, all of 1.0 seconds,
 1.1 seconds, 1.3 seconds, and 2.3 seconds, are (?) both correct and
 expected forms, as opposed to 1 second and 2 seconds.


And that's fine.  So do that.  But don't stick a big warning there!

If I specify a precision of 0, then it should be   1 second.  If the
precision is 1 then 1.0 seconds is fine.

John


Re: KLocalizedString regression

2011-03-25 Thread Chusslove Illich
 [: John Tapsell :]
 If the number is small, I want to show 2 seconds but if it's large I
 want like 2.2e4 seconds.

 You're saying that my API needs to require the user to now pass *two*
 strings for that?

Well, yes. Two grammar-wise different text fragments (enumerable vs.
measurable quantities) are being used in alternation, so each should be
represented by its own string. The author of KUnitConversion wanted the same
feature, so there too we ended up defining two strings, e.g:

  setDefaultUnit(UP(Meter, 1,
...
ki18nc(amount in units (real), %1 meters),
ki18ncp(amount in units (integer), %1 meter, %1 meters)
  ));

(from kdelibs/kunitconversion/length.cpp).

In my opinion, however, this alternation is bad style-wise. The display
should use either the measurable form throughout (2.0 seconds; 2.2e4
seconds), or the enumerable form throughout (2 seconds; 6 hours 6 minutes).

-- 
Chusslove Illich (Часлав Илић)


signature.asc
Description: This is a digitally signed message part.


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 13:19, Chusslove Illich caslav.i...@gmx.net wrote:
 [: John Tapsell :]
 If the number is small, I want to show 2 seconds but if it's large I
 want like 2.2e4 seconds.

 You're saying that my API needs to require the user to now pass *two*
 strings for that?

 Well, yes. Two grammar-wise different text fragments (enumerable vs.
 measurable quantities) are being used in alternation, so each should be
 represented by its own string. The author of KUnitConversion wanted the same
 feature, so there too we ended up defining two strings, e.g:

      setDefaultUnit(UP(Meter, 1,
        ...
        ki18nc(amount in units (real), %1 meters),
        ki18ncp(amount in units (integer), %1 meter, %1 meters)
      ));

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?

 In my opinion, however, this alternation is bad style-wise. The display
 should use either the measurable form throughout (2.0 seconds; 2.2e4
 seconds), or the enumerable form throughout (2 seconds; 6 hours 6 minutes).

But what if I want to allow both?  This is for labelling the axis of a
graph.  I now have to have an API and forces the users to give the
same string twice.


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 13:59, John Tapsell johnf...@gmail.com wrote:
 On 25 March 2011 13:19, Chusslove Illich caslav.i...@gmx.net wrote:
 [: John Tapsell :]
 If the number is small, I want to show 2 seconds but if it's large I
 want like 2.2e4 seconds.

 You're saying that my API needs to require the user to now pass *two*
 strings for that?

 Well, yes. Two grammar-wise different text fragments (enumerable vs.
 measurable quantities) are being used in alternation, so each should be
 represented by its own string. The author of KUnitConversion wanted the same
 feature, so there too we ended up defining two strings, e.g:

      setDefaultUnit(UP(Meter, 1,
        ...
        ki18nc(amount in units (real), %1 meters),
        ki18ncp(amount in units (integer), %1 meter, %1 meters)
      ));

 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?

 In my opinion, however, this alternation is bad style-wise. The display
 should use either the measurable form throughout (2.0 seconds; 2.2e4
 seconds), or the enumerable form throughout (2 seconds; 6 hours 6 minutes).

 But what if I want to allow both?  This is for labelling the axis of a
 graph.  I now have to have an API and forces the users to give the
 same string twice.


Chusslove, I just had an idea - so okay, if I'm forced to work around
this feature, could I do:

string.remove((I18N_PLURAL_ARGUMENT_MISSING));

This string won't change, and isn't translated right?

John


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 14:20, Thiago Macieira thi...@kde.org wrote:
 Em sexta-feira, 25 de março de 2011, às 13:59:11, John Tapsell escreveu:
  Well, yes. Two grammar-wise different text fragments (enumerable vs.
  measurable quantities) are being used in alternation, so each should be
  represented by its own string. The author of KUnitConversion wanted the
  same feature, so there too we ended up defining two strings, e.g:
 
       setDefaultUnit(UP(Meter, 1,
         ...
         ki18nc(amount in units (real), %1 meters),
         ki18ncp(amount in units (integer), %1 meter, %1 meters)
       ));

 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?

 No. You haven't said anything about your API yet.

 Maybe the problem is in the API. But we don't know, because you haven't
 included a link to what API you're talking about.

I have a widget, KSignalPlotter, which plots data points.

The usage is:

KSignalPlotter plotter;
plotter.setUnit( ki18ncp(Units, %1 second, %1 seconds) );
plotter.addBeam(Qt::red);
plotter.addSample( QListqreal()  2 );

For example.

The axis will then be labelled using the unit string.  The precision
will be calculated automatically.

 Huh? Why do you want to show 1.0 seconds in the axis? Shouldn't you have
 1.0 in the axis and then seconds in the axis label?

Because typically we have a lot more horizontal space than vertical
space.  Adding room for axis labels would take up valuable vertical
space.

John


Re: KLocalizedString regression

2011-03-25 Thread Thiago Macieira
Em sexta-feira, 25 de março de 2011, às 14:39:22, John Tapsell escreveu:
 I have a widget, KSignalPlotter, which plots data points.

 The usage is:

 KSignalPlotter plotter;
 plotter.setUnit( ki18ncp(Units, %1 second, %1 seconds) );
 plotter.addBeam(Qt::red);
 plotter.addSample( QListqreal()  2 );

 For example.

 The axis will then be labelled using the unit string.  The precision
 will be calculated automatically.

So you might have a graph showing 1, 2, and 3 where the unit is 2.2e4
seconds ?

Shouldn't you show instead 2.2e4, 4.4e4 and 6.6e4 with a unit of seconds ?
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.


Re: KLocalizedString regression

2011-03-25 Thread Thiago Macieira
Em sexta-feira, 25 de março de 2011, às 15:17:33, John Tapsell escreveu:
 The graph would show  1 second  2 seconds 3 seconds   on the
 axis in this case.

IMHO it should show:
1 s
2 s
3 s

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


signature.asc
Description: This is a digitally signed message part.


Re: KLocalizedString regression

2011-03-25 Thread Chusslove Illich
 [: 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.

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]

This is how graph axes are normaly presented, at least in engineering
fields, and it would sidestep the complete issue. (I realize that this
suggestion is off-topic as such for this thread, but I couldn't resist since
I have strong feelings about proper graph plotting.)

-- 
Chusslove Illich (Часлав Илић)


signature.asc
Description: This is a digitally signed message part.


Re: KLocalizedString regression

2011-03-25 Thread John Tapsell
On 25 March 2011 21:42, Chusslove Illich caslav.i...@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.

John