[Top][All Lists]

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

Re: [Gnumed-devel] Country zones and i18n

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Country zones and i18n
Date: Thu, 17 Nov 2011 22:54:08 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 17, 2011 at 06:20:20PM +0000, Jim Busser wrote:

> 2) next comes the question of whether the pack contains
>    staging values that represent *accented or language
>    variants* and how to manage them. This is where I am needing
>    more thoughts. A data packer needs to consider
>       - when a set or subset of city names does not yet exist in GNUmed
>               then -- before adding them to dem -- 
>                       where these names may represent variants for which 
> translations exist
>                       --> look for matches on language in i18n.translation
>                               where .lang = 'specify a language'
>       - failing which, the only choices are to
>               (a) add them to dem. despite that they are accented etc or

I don't see the problem with that. After all, that's what
actually *belongs* into dem.*. Everything else is but a

> For Brazil, the source seems to have translations for cities but not for 
> streets. So it should be

> - feasible to populate i18n.keys and i18n.translations
> with an accented form, however shall that form be available
> only to users whose environment or language is set to
> portuguese?

That problem is solved by using the target language "generic".

Remember, however, that that's only an ugly hack -- the real
solution would be to identify the in-app queries which would
benefit from applying an unaccent() and add that to those

> - not feasible to populate dem.street with unaccented values (unless or until 
> people can point me to a tool)

unaccent() ?

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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