Re: Workplaces and Languages was Re: [Gnumed-devel] Release 0.5.rc3

[Karsten Hilbert]

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