[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Suggestions for i18n-friendly entry of duration data?
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2004-04-06 22:31:10
Message-ID: 200404070031.10768.nicolasg () snafu ! de
[Download RAW message or body]

I have already thought about similar situations (Long names of charsets/
encodings in kdelibs, zoom in KOffice) and I have found a full usable tracks, 
which you might be able to use.

The first is I thing to split the unit and the number with a regular 
expression. I suppose that this regular expression has to be made 
translatable.

For example of such regular expression, see
koffice/lib/kofficeui/koUnitWidget.cc (function 
KoUnitDoubleValidator::validate, in this form only in KOffice CVS HEAD)
or in koffice/filters/kword/abiword/ImportHelpers.cc (function 
ValueWithLengthUnit)

The above functions do not translate the unit name but I do not really a 
problem to do so. (Also the unit widgets assume suffix and cannot work with 
prefix. But that too is not really a  limitation at the level of the regular 
expression, assuming that it is translatable.)

(Also David Faure had suggested context menu for the units in the unit 
widgets. But that is not really the topic of your question.)

Also as last note, may be time unit should be added to the unit widgets too 
(with a flag: length or time.)  Or perhaps not...

Have a nice day!

On Tuesday 06 April 2004 20:28, Shaheed wrote:
> [ Please CC: me and Dag on replies as we are not subscribed ]
>
> Hi all,
>
> In KPlato, there is a need to support convenient and fast entry of duration
> information. The sorts of duration involved might be 1.5 days or 6.5 weeks
> or 2.3 years. We are looking for a GUI paradigm to support this, and which
> is an improvement over what we have today (checkout CVS head if you are
> interested).
>
> One attractive idea is that we should allow the entry of strings like
> "1.5d", "6.5w" for example, but we are a bit concerned as to the i18n
> impact of this approach on reliably parsing the input [1].
>
> Can anyone provide suggestions on this point?
>
> An additional minor point is that we would like to find a paradigm which is
> suited for a dialog, as well as a spreadhseet-like format for bulk
> entry/review of data.
>
> Thanks, Shaheed
>
> [1] We presume that both the decimal point and the suffix are subject to
> change, that the suffix may become a prefix, and we would have to change
> the parser based on the user's current locale setting or somesuch. A
> configuration dialog for this is possible, but seems a rather rubbish
> solution!

[prev in list] [next in list] [prev in thread] [next in thread]