Re: [Gnumed-devel] Country zones and i18n

[Karsten Hilbert]

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
crutch.

> 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
queries.

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

unaccent() ?

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346