[Top][All Lists]

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

Re: [Gnumed-devel] Country zones and i18n

From: Busser, Jim
Subject: Re: [Gnumed-devel] Country zones and i18n
Date: Wed, 16 Nov 2011 21:40:31 +0000

On 2011-11-16, at 9:35 AM, Karsten Hilbert wrote:

> 2. Establishing a mechanism to make available street / city preloads (which 
> presently we have only for AU and BR and … ??)

If we try to keep to the plan of populating tables with unaccented values, then 
data packs whose sources provide accented values would best substitute 
looked-up values, for example if we have a source file containing {street, city}

        { 'Popular Nova', 'Corumbá' }
        { 'Cavaleiros' , 'Macaé' }
        { 'Jardim Independência III' , 'Sarandi' }

then values in i18n.translations would allow street

        Popular Nova

to be created with reference to the city Corumba and street


to be created with reference to the city Macae.

Notice, however that city 'Sarandi' has no accents. What it means is that even 
if 'Sarandi' had been added to i18n.keys, there will be nothing in 
i18n.translations *unless* a translation had already been created for it, in 
spite of no accents:

                select i18n.upd_tx('pt_BR', 'Sarandi', 'Sarandi');

Is that a reasonable approach, to populate i18n.translations with values where

        orig = trans

or should I be trying to figure out a way to make the query conditional?

        case when a value exists in i18n.translations, then use that value, 
failing which
        when a value exists in dem.urb, then use that value

        --> i.e. do not create new urbs if it is possible that the new values 
would be accented?

-- Jim

reply via email to

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