On Wed, Jul 08, 2009 at 12:54:18PM -0700, Jim Busser wrote:
- when I did not yet set my local db "currently selected
language", then
when log in, I am warned that the currently-selected language
(none) did
not match my system language (en_DK), did I wish to set it as
en_DK? and
I clicked "Set".
Ah, you found a bug :-) That should have said something
more specific along the lines:
There is no language set in the database yet,
shall I set it to the user interface language ?
Fixed.
When you clicked "set" it tried to set it but will have
failed because there is no translation into en_DK in the
database. That's why you saw this:
- querying the local database (Reports plugin, run: select *
from i18n_curr_lang),
I saw only a single record
db_user = gm-dbo lang = en_DK
If you check the log you will notice how it failed to set
the language and then forced it.
and as this was the only record, I imagine this is "currently
selected"
No. Since you weren't "gm-dbo" this wasn't your current db
language. To show that you'd want to run "select
i18n.get_curr_lang()".
However, this also shows a bug: i18n.force_curr_lang wrongly
sets the language for gm-dbo rather than the current user.
Fixed :)
- then I went to Preferences > Database > Language and selected
"en_ES"
and when I re-ran the query I saw
db_user = gm-dbo lang = en_DK
db_user = any-doc lang = en_ES
You probably mean es_ES and that worked because there *are*
Spanish strings in the database and thus the faulty
force_curr_lang didn't get used.
therefore Preferences > Database > Language appears to set a language
for the individual GNUmed account any-doc
Same with the startup except for the bug.
When I next login I am advised: "The currently selected database
language ('es_ES') does not match the current system language
(en_DK). Do
I want to set the database language to en_DK?
What is the "system language" here supposed to mean?
The language your desktop is / applications are in.
I must point out
that when I click "yes", since I seem to be responding to the
"es_ES", I
was figuring the query would next return
db_user = gm-dbo lang = en_DK
db_user = any-doc lang = en_ES --> en_DK
That is the correct excpectation except for the bug.
but it does not... I only get what was *already* en_DK
db_user = gm-dbo lang = en_DK
... where did any-doc go?
The bug ate it.
3) for the database, the original (basal) language will always be
english
I think you might need to explain that assumption some more
else I won't be able to properly respond to it.
Consider someone adding an encounter type but only providing
a "local name". This will create an encounter type with the
local name also being used as the "encounter type
description". There will be no English involved with that.
unless and until much would be rewritten. Therefore instead of
declaring a "database language" can we understand ourselves to be
offering users to declare (instead of database) the
customary local language
But that only applies to the database. How are they to
differentiate that from their frontend language ?
and, in place of "system", whatever we wish less ambiguously (mis)
understood by "system"
I'd be happy to use a better term.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
_______________________________________________
Gnumed-devel mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnumed-devel
Picture 27.png