Mike Alexander wrote:
--On March 16, 2010 10:17:37 AM +0100 Christian Stimming
<stimm...@tuhh.de> wrote:
Zitat von Jeff Kletsky <gnuc...@allycomm.com>:
#define ACCOUNT_OPTIONS_SECTION "Accounts"
#define TRADING_ACCOUNTS_OPTION "Trading Accounts"
Presently, make-gnucash-potfiles.in does not look at .h files for
translatable strings, so even after adding
#include <glib/gi18n.h>
and marking the strings, they don't make it into POTFILES.in
What approach is recommended for resolving this?
* Add an exception to make-gnucash-potfiles.in
Yes.
* Use _(ACCOUNTS_OPTIONS_SECTION) and don't translate the raw define
Yes. In the #define lines, the strings should be marked with the N_(
... ) macro, so they are still just a const char* literal for the
compiler's point of view, but they make it into gnucash.pot:
#include <glib/gi18n.h>
#define ACCOUNT_OPTIONS_SECTION N_("Accounts")
Subsequently, in places where the defines are being used for
human-visible display, they need to be translated writing
_(ACCOUNTS_OPTIONS_SECTION).
* Change .h to .c and leave people wondering why a .c file is being
#include-d
No.
This is my fault. These #defines are used in two places. One is
qofbook.c where they are used to access the slot holding the value of
this option. These should, of course, not be translated. The other
is in business-prefs.scm where they are used as the section and name
parameters to gnc:make-simple-boolean-option. The other calls to
gnc:make-...-option in this file use (N_ ...) for the name and section
parameters. These parameters are used for both slot access and for
the UI. There must be some special magic to cause them to be
translated for the one case and not the other.
I think the correct fix is to leave the #defines alone (the C code
only uses these for slot access) and change the two lines in
business-utils.scm to read
(define gnc:*book-label* (N_ ACCOUNT-OPTIONS-SECTION))
(define gnc:*trading-accounts* (N_ TRADING-ACCOUNTS-OPTION))
Unfortunately I've been out of town for the last month and I need to
do a bunch of updating and building before I can test this fix.
However it makes things consistent with the other constants defined in
business-utils.scm and used in business-prefs.scm so it may be ok.
It would probably also be ok to include the N_(...) on the #defines
but doing it like I describe would be more consistent with the other
strings used in business-prefs.scm.
I think things do mostly work the way they are, except that the
strings probably aren't marked for translation as they should be.
When I added this code I tested it by adding a fake translation for
"Trading Accounts" and it showed up in the UI.
This is all very confusing to me. All of the calls to
gnc:make-...-option use (N_ ...) for the section, name, and
description parameters, but somehow they get translated anyway. I
think I tracked this down once, but I've forgotten how it works now.
Mike
I've got it running here (though have yet to confirm translation works)
-- the last little trick was to get Swig to recognize the #define
N_("some string to be translated") construct so that the variable would
be created in the Guile side of the house. (I also changed to
KVP_OPTIONS_PATH to be more consistent with usage elsewhere in the code,
as well as a naming convention for the section/option that was a little
more understandable to me when extended.)
#ifndef SWIG /* swig doesn't see N_() as a string constant */
#include <glib/gi18n.h>
#else
#define N_(string) string
#endif
[...]
#define KVP_OPTION_PATH "options"
/*
* Various option sections and options within those sections
*
* At least through 2.3.10, the key and the display string are tied,
* coupling the data with its representation in the UI
* and is not locale-independent (translated strings used as keys)
*/
#define OPTION_SECTION_ACCOUNTS N_("Accounts")
#define OPTION_NAME_TRADING_ACCOUNTS N_("Trading Accounts")
#define OPTION_SECTION_BUDGETING N_("Budgeting")
#define OPTION_NAME_DEFAULT_BUDGET N_("Default Budget")
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
