gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Translatable database strings from within the client


From: Jim Busser
Subject: Re: [Gnumed-devel] Translatable database strings from within the client
Date: Wed, 10 Aug 2011 16:16:57 -0700

On 2011-08-10, at 2:34 PM, Karsten Hilbert wrote:

> On Wed, Aug 10, 2011 at 02:28:20PM -0700, Jim Busser wrote:
> 
>> domain not specified, deriving from script name
>> text domain is [gnumed]
>> searching message catalog file for system locale [en_CA]
>> ${LANGUAGE} = [None]
>> ${LC_ALL} = [None]
>> ${LC_MESSAGES} = [None]
>> ${LANG} = [en_CA.UTF-8]
>> preferring local message catalog
>> looking above binary install directory 
>> [/Users/djb/git/gnumed/gnumed/gnumed/po]
>> looking in binary install directory 
>> [/Users/djb/git/gnumed/gnumed/gnumed/client/po]
>> system is POSIX, looking in standard locations (see Python Manual)
>> looking at ${GNUMED_DIR}
>> ${GNUMED_DIR} not set
>> trying [/Users/djb/git/gnumed/gnumed/gnumed/po](/en_CA/LC_MESSAGES/gnumed.mo)
>> trying 
>> [/Users/djb/git/gnumed/gnumed/gnumed/client/po](/en_CA/LC_MESSAGES/gnumed.mo)
>> does not translate: [Translate this or i18n will not work properly !] => 
>> [Translate this or i18n will not work properly !]
> 
> Well, it says it right there.
> 
> Sure, this is a bit misleading since the "translation" is
> linguistically correct. If you alter the translation (in any
> way) it will likely start working.

Thanks for helping clarify this. Can you enlighten as to what role would be 
played by

        /en_CA/LC_MESSAGES/gnumed.mo

as to how that kind of pseudo-argument (?) is intended to be processed?


Also, I am thinking that the above translation (needing .po and .mo files) … it 
is about the UI translation and nothing to do with the in-backend database 
strings so maybe under the wrong thread but anyway…

… if UI translation depends on .mo files (none of which exist in my cloned git 
repo) then -- in order for i18n to be supported running from git -- a user 
would need to have a suitable .mo already installed in a standard location 
(which is perhaps a scripted part of packaging releases) e.g.

in my 0.9.9 client tarball I can find

        de-gnumed.mo
        el-gnumed.mo

So if all of this correct, even if I made changes in a

        /Users/djb/git/gnumed/gnumed/gnumed/client/po

wouldn't

        ~/git/gnumed/gnumed/gnumed/client/po/create-gnumed_mo.sh

have to be manually called?

-- Jim


reply via email to

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