gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: 0.5.rc4 Address entry issues


From: Karsten Hilbert
Subject: [Gnumed-devel] Re: 0.5.rc4 Address entry issues
Date: Tue, 21 Jul 2009 18:39:53 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Mon, Jul 20, 2009 at 04:20:21PM -0700, Jim Busser wrote:

> Moving on, if in the dob I input a disallowed delimiter (e.g. "."
> instead of "-")

That is not possible here. I do have "." but cannot input
"-". Are you using the old-style new-patient widget in which
I will not fix usability glitches anymore. If not it may be
due to locale differences - the date selector is sensitive
to the locale.

If so then ...

> Is there any option to liberalize the allowable delimiters?

... none that I know.

> I get a beep and the status line says
> 
>       The content is invalid. It must match the pattern [.+]

That doesn't belong to the DOB but rather to the field you
tabbed into the DOB from.

> What is "the pattern [.+]" ?

The regular expression "anything but not empty" which upon
losing focus the phrasewheel checks its content against.

I have now made the error configurable so we can later set
it explicitely in any phrasewheel we desire -- that's low
hanging fruit for Newbies, too.

I have made the default at least include the class name so
we've got some idea of where the generic message comes
from... :-)

> Also, even when I next abandon creating the patient, and if I would
> refresh the status line by going to the menu GNUmed > Check for
> updates, then as soon as I next try to create a person, the status
> line immediately again shows
> 
>       The content is invalid. It must match the pattern [.+]
> 
> despite that I did nothing yet wrong on the new attempt.

I am not 100% sure why but it does come from the field
that's in focus - the lastname - it somehow does an early
check for reasons I don't yet fully understand.

Oh, wait, probably that's because we are explicitely setting
the focus before letting the user do something:

Focus sits in the first field created - the lastname field.
Then the other fields are created. Focus doesn't move so no
check. Then we set the focus meaning focus does
(technically) move - although visually it may still be the
same field - hence the check is done where the focus leaves
from - even though that's the same field as the one that is
entered ...

Strangely though, if we *don't* explicitely set the focus
we don't have *any* initial focus ... ;-)

> How are the labels managed?

In code (and translated, of course).

> For example in this screenshot, I would
> (instead of "Place") use "City" ... does this require to establish a
> .po file for _CA?

That would work, anyway.

> As a result, I would then be unable to use en_DK if I wished the ISO
> date format, unless I would (locally) supply a "pretend" .po for
> en_DK?

Huh ? But you *would* be using that .po in order to change
Place to City ?

On that particular label, however, I am sure open to
discussion. We need a label which applies to as many of:
town(ship), venue, city, dwelling, megalopolis, village, ...

In German we've got "Ort" meaning something like "Locality".
"Urb" would apply but is IMO inacceptable user-side.

> What happens if "Place" means something else in a different location
> in GNUmed?

It'll need a different translation. Yes, that's a conceptual
problem with the gettext system for which there is no clean
cure. Two approaches are used to alleviate it:

1) include local formatting and/or whitespace into the translated string

        this is inconvenient for labels

2) use a suffix or prefix on the string which is then removed in code

        Say, I write in the code

                translation = _('new-patient-label::Place')
                label = translation.remove('new-patient-label::')

        translators would see the string 'new-patient-label::Place' and know
        what to do - they must, however, either include "new-patient-label::"
        as is or leave it out altogether from their translation

        this, however, requires a tiny bit more processing during display

        we do use this in some places, eg. for "translating" (==
        configuring) date label format strings for the
        measurements grid ...

> is this a responsibility that falls on the programmers to
> avoid re-using a default label with GNUmed except that it would mean
> the same thing in the different parts?

That is another approach: avoid the problem.

> Whereas the person-creation widget and Demographic plugin columns
> say "Place" the edit detail field says "Town" ... shall these be the
> same? I could even better accept "Urb" -- or "Urb / City" or "Urb /
> Town" -- than "Place"

See above, but, yes, and, yes this is a todo.


> When I input into a region the abbreviation for my local region "BC"
> for "British Columbia" I fail to remember (but surmise) that "BC" is
> a short form already stored in the backend,

it is

> however if I would wish
> "Baja California" and "Basilan City" removed

you cannot unless you delete it from the backend

> until such time as I
> actually had patients form those regions how would that be achieved
> when bootstrapping a production database?

You would need to comment out the appropriate SQL files or
lines therein. It is more trouble than gain.

> (By the way -- the next time -- the phrasewheel offered me the
> values in a differently-listed order, does it pull from existing
> values in the database?)

It does but already on the first run. The second run,
however, probably had a different (better ?) sort order
because it had more context ! Such as a country :-)  It is
context sensitive to that. So if you enter street, urb,
country, state they all influence the sort order of each
other.

> When I would enter a person's "Region" and select an existing value
> and press "return", there is no autocompletion of the country,

Because the phrasewheel doesn't support that.

It does, however, sort Germany (Deutschland) atop
Afghanistan just fine when I set the region to Sachsen,
which is a State in Germany.

>  and I
> am asked to select a value among those listed for Country that are
> not filtered based on Region.

it should be sorted by region (matches on top)

> When I enter an existing value of postal code am I supposed to get
> autocompletion of the street and city and region and country so that
> I only need to enter the "Number"?

Nope, only the context for the phrasewheels is set so that
matches will be on top in the drop down.

> What happens if two countries share a postal code?

several matches will be on top

> Can more width be assigned to DOB?

I have done so previously and it worked for me. I've upped
it somewhat again, however.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346




reply via email to

[Prev in Thread] Current Thread [Next in Thread]