[Top][All Lists]
[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
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, (continued)
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, Karsten Hilbert, 2009/07/23
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, Jim Busser, 2009/07/23
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, Jim Busser, 2009/07/23
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, Karsten Hilbert, 2009/07/24
- Re: [Gnumed-devel] Re: 0.5.rc4 Address entry issues, Karsten Hilbert, 2009/07/28
[Gnumed-devel] Re: 0.5.rc4 Address entry issues, Karsten Hilbert, 2009/07/21
[Gnumed-devel] Re: 0.5.rc4 Address entry issues,
Karsten Hilbert <=