[Gnucash-changes] r13639 - gnucash/trunk - * lib/libqof/backend/file/qsf-backend.c: add <locale.h>

[Neil Williams]

On Thursday 16 March 2006 2:21 pm, Derek Atkins wrote:
> Neil Williams <linux at codehelp.co.uk> writes:
> >> 	* lib/libqof/backend/file/qsf-backend.c:  add <locale.h>
> >> 	  Note:  it think it's probably wrong to set the locale here.
> >
> > It's a GModule - it needs to load the locale itself according to whether
> > the backend is loaded from internal gnucash (use the gnucash text domain)
> > or libqof1 (use the qof text domain).
>
> Eh?  A GModule is just a shared library, nothing more.  There's
> nothing special about a GModule; the g_module API is just a wrapper
> around dlopen(), and dlsym(), pretty much.

The module is loaded by libqof which in turn does not know the identity of the 
application. How can it? The application can't translate these strings, the 
source does not exist in the tree when qof is used externally (e.g. 
pilot-qof).

There's absolutely no point in duplicating these strings into placeholder 
locations in every application that ever used libqof - even then I'm not 
convinced gettext would replace the (untranslated) strings in the QSF Gmodule 
with the placeholder (translated) strings in the application.

> > Yes.
>
> Why?  What's the failure mode here?

Untranslatable strings. gettext cannot locate the marked up strings because 
they exist in the QOF source tree, not cashutil or pilot-qof. Only QOF can 
therefore make these strings available for translation via a qof.pot file and 
install them in a QOF directory as .gmo files.

gnucash is a special case - the strings do exist but only when used 
internally. When gnucash uses libqof externally, gettext still cannot locate 
the strings to be translated because they are being loaded from an external 
library (the identifier has changed because qof does not use the lib/libqof/ 
prefix).

> >> Shouldn't the APP
> >> +	 * have already done this?
> >> +	 */
> >
> > There is no "app", it's a GModule, loaded independently by libqof1.
>
> There most certainly is an application!  What the heck do you think is
> running?  There's some executable that loaded the module.

Via the library, not directly. The library doesn't know the identity of the 
application, neither does the backend. Therefore gettext has to load the 
strings from the only known domain: qof.

QOF therefore has it's own translations for these 6 strings so that they can 
be translated when qof is used externally.

> That 
> executable (gnucash, cashutil, pilot-qof) most likely already ran
> setlocale().  Doing it again is..... wrong.

The translated strings aren't part of pilot-qof, they can't be - qsf-backend.c 
doesn't exist in the pilot-qof (or cashutil) source tree for gettext to 
process. Therefore gettext cannot put the translations into place - it has no 
knowledge of them unless QOF loads them in it's own textual domain.

> >     The module
> > knows nothing of the app using the library, therefore it cannot locate
> > the text domain, so it needs it's own - which it has. libqof1 is
> > translated by the GNU TP.
> > http://www.iro.umontreal.ca/translation/registry.cgi?domain=qof
>
> I don't underdstand this statement.  Could you please go into more
> detail about how it "cannot locate the text domain"?

pilot-qof loads libqof1 and doesn't load the backend until a session operation 
is required. It then calls a libqof function that executes the load. It is 
only at this point that the strings in qsf-backend.c can be translated.

gettext places all translated strings in locations on the filesystem dictated 
by the textual domain - usually the name of the 
package. /usr/share/locale/LC_MESSAGES/gnucash or .../qof/ or ../pilot-qof.

gettext can only put those strings into the location determined by the textual 
domain if it can find the marked up strings in the source tree identifying 
itself as that domain - otherwise they get skipped. So pilot-qof contains 79 
translated messages. QOF contains 6.

The 6 strings in QOF are all in the QSF backend - more would be added with 
other backends - and are not present anywhere in the pilot-qof source tree. 
gnucash is a special case.

gettext cannot locate these strings, it cannot put them into the pilot-qof.pot 
file, it cannot use them if they are put into a po file within pilot-qof. 
gettext can only load them from a pot file created from the qof source tree - 
i.e. qof.pot, creating a textual domain called 'qof', creating installation 
directories of LC_MESSAGES/qof/ and requiring that when the backend loads, it 
calls gettext with this domain to locate the translations.

The only way to load these strings is to give them a textual domain (basically 
a location in the filesystem) of their own. That is the QOF textual domain.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060316/c21205e8/attachment.bin