Re: [Gnumed-devel] Country zones and i18n

[Busser, Jim]

On 2011-11-16, at 2:32 PM, Karsten Hilbert wrote:

>    { '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
> 
>    Cavaleiros
> 
> to be created with reference to the city Macae.
> 
> -> Values in i18n.translations do not play a role in
>   whether such references can be created ?

I agree it is possible to create a row in

        dem.street

in which the id_urb is a value referencing the dem.urb row for the Brazilian 
city 'Corumba' meaning that yes, it is technically possible to create such a 
row even if the table i18n.translations were empty. The problem is how, using a 
SELECT, to figure out the referent record in dem.urb where that urb's name (in 
dem.urb) is 'Corumba' whereas what we have in the source table is 'Corumbá'

This is where values in i18n.translations *could* (but won't necessarily) 
provide the means to map the values.


> 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
> 
> -> Indeed.
> 
> *unless* a translation had already been created for it, in spite of no 
> accents:
> 
>        select i18n.upd_tx('pt_BR', 'Sarandi', 'Sarandi');
> 
> -> Correct but I fail to see the significance of this
>   excercise (which isn't possible AFAIR since upd_tx()
>   cross-checks orig and trans.

oops I had been judging only from the table specification using

        \d+ i18n.translations

which has no such constraint and therefore if one were to bypass the function 
select i18n.upd_tx() it could still be achieved. Are you inclined to add the 
constraint to the table specification?

-- Jim