gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: Possible solution for altering date formats (Debi


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] Re: Possible solution for altering date formats (Debian)?
Date: Tue, 7 Jul 2009 17:14:25 +0200
User-agent: KMail/1.12.0 (Linux/2.6.27.23-0.1-default; KDE/4.2.95; i686; ; )

Am Dienstag 07 Juli 2009 02:07:15 schrieb Jim Busser:
> On 2-Jul-09, at 2:04 AM, Karsten Hilbert wrote:
> > On Wed, Jul 01, 2009 at 07:19:52PM -0700, Jim Busser wrote:
> >>> PG needs it to know how to sort data, among other things. It
> >>> cannot change it either, even accepting changes in sorting,
> >>> because that would invalidate indexes.
> >>
> >> Don't  the indexes influence sorting?
> >
> > No, it's the other way round.
> >
> >> Is it just the character set that is important to the consideration?
> >
> > No. The set itself doesn't have an inherent ordering.
> >
> >>>> Alternatively in the GNUmed client menu
> >>>>
> >>>>  GNUmed > Options > Database > Language
> >>>>
> >>>> there exist about five options none of which are en_DK
> >>>
> >>> That is only about the language used to translate strings
> >>> inside the database - nothing to do with the client user
> >>> interface as such.
> >>
> >> Is the above selection only relevant to  i18n .po files (if they
> >> would
> >> have been supplied)?
> >
> > Not at all. Only to the language setting used inside the
> > database. That is why it is grouped under "Database", after
> > all.
>
> Apologies for my ongoing slowness here. The client user interface is
> controlled, among other things, by:
> - the machine's (or overriding user-level) LANG and LC_ settings
> - optionally, the provision and configuration, at the machine-level,
> of a binary message catalog which provides a translation for all of
> the English program message strings (per wiki FrontendI8n)
> - whichever values had been provided, by the praxis, for things like
> encounter types, document types etc
>
> There is also in the wiki "BackendI18N" which includes "How to
> provide a translated column", "How to add a translation target
> (language) to the database" and to "allow user to select a default
> output language".
>
> So it is seeming to me that the selecting / setting of a database
> language *does* (or has been intended to) affect what the user sees?
>
Correct. We are talking about two different things here. mo files are for the 
GUI like the abutton reading 'Speichern' instead of 'Save'

The database *content* has translations as well so a document type 'discharge 
from surgery' you saved at your end turns up as 'Entlassung aus der Chirurgie' 
It is the same type but is displayed in the local language. In other systems I 
would save 'Entlassung aus der Chirurgie' and you would get to see *that* 
because those systems save the string instead ob a translatable object. But 
since you don't speak German that would make no sense to you.

Imagine you are a Canadian doctor working in Germany. You could select 
'discharge from surgery' in your personal  running GNUmed and you German 
collegue would log in and see 'Entlassung aus der Chirurgie' because it is 
translated at database level. If no translation exists he would see 'discharge 
from surgery'.




reply via email to

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