translations and option definitions

[Derek Atkins]

Neil, if you're doing all this in C then what's the point of the XML file
anymore?

-derek

Quoting Neil Williams <linux at codehelp.co.uk>:

> On Saturday 03 September 2005 10:34 pm, Christian Stimming wrote:
>> Ok, now let's clear up this translation problem.
>
> It is getting better with these new functions:
>
> typedef struct QofBackendOption_s {
> 	KvpValueType type;
> 	const char *option_name;
> 	const char *description;
> 	const char *tooltip;
> 	gpointer value;
> }QofBackendOption;
>
> void qof_backend_prepare_frame(QofBackend *be);
>
> void qof_backend_prepare_option(QofBackend *be, QofBackendOption *option);
>
> KvpFrame* qof_backend_complete_frame(QofBackend *be);
>
> typedef void (*QofBackendOptionCB)(QofBackendOption*, gpointer data);
>
>> Here's what I understood
>> about these obnoxious :-) data-store-backend options: Eventually, the
>> backend options should be passed as a kvp_frame. The collection of all
>> options is a kvp_frame with all options as sub-kvp_frames. For each option,
>> there is a name which is the path to that kvp_value. Each option has a type
>> which is implicitly defined by the type of that kvp_value. (Note: You
>> really need to do something about boolean options! Either add a "gboolean"
>> kvp_value or decide on a fixed convention.)
>
> There's been a need for a KVP_TYPE_BOOLEAN for some time. I will look at it.
> Temporarily, I'll continue with "TRUE" or "FALSE" as strings.
> (untranslated!):-)
>
>> Each option has a
>> human-readable string containing the description of it. And an option also
>> has a human-readable tooltip string.
>
> Yes. I've been doing some work on this in the meantime:
>
>>   kvp_frame *my_options = from_somewhere(blabla);
>
> QofBackend *be;
> be->backend_configuration
>
>> The human-readable strings are english. Now let's translate them. If I
>> already know that the string is located at "firstoption/description", then
>> this is done by
>>
>>   kvp_frame_set_string(my_options, "firstoption/description",
>>     gettext(kvp_frame_get_string(my_options, "firstoption/description") )
>
> Yes, done that.
>
> qof_backend_prepare_frame(be);
> option->option_name = GNC_BE_DAYS;
> option->description = _("Number of days to retain old files");
> option->tooltip = _("GnuCash keeps backups of old files, "
> 	"this setting dictates how long each is kept");
> etc.
> qof_backend_prepare_option(be, option);
> return qof_backend_complete_frame(be);
>
>> and that's it. Conveniently the macro _() is defined as an alias for
>> gettext(), so writing _(kvp_frame_get_string...) is just the same. It
>> should be clear how to achieve this in a generic form by
>> kvp_frame_for_each_slot() and so on.
>
> Doing that now.
>
>> The only other part that has to be ensured is that *at compile time* the
>> original english strings need to be found by the xgettext program so that
>> they will appear in po/gnucash.pot as a so-called "msgid". *If* a string is
>> in a C source file *and* it is enclosed by _() then xgettext will
>> automatically add that string as msgid.
>
> Done: see the option preparation above.
>
>> Back to the option definition and translations. If the option definition is
>> done inside a C source file, very well, then the msgids will simply be
>> retrieved by xgettext from that C source file.
>
> I've decided to implement this. It's just a case of making a usable method of
> retrieving the option details OUT of the frame. kvp_frame_for_each_slot isn't
> recursive so I'm just putting together a foreach that will take the frame and
> return the options one at a time.
>
>> There is only one open question: Which package should have these strings in
>> its .pot file, i.e. in which pot file should the msgids eventually be
>> located? That question is easily answered: If the string will be displayed
>> in the Gnucash GUI, then it *has* to appear in gnucash's own pot file.
>
> Not exclusively the gnucash po file. By calling gettext on the library *as it
> is loaded* by whichever application uses it, the translations from
> gnucash-gui or cashutil are used. It does mean gnucash-gui and cashutil po
> files need to be built from the same source tree.
>
>> Gnucash has so much more translators and translations than any other
>> involved project. Any translations of strings in Gnucash simply *have* to
>> be located in gnucash's own gnucash.pot.
>
> But CashUtil needs them too. It already has all the QofBackendError messages
> re-formatted for a CLI output (with less \n and a standardised "%s:", PACKAGE
> start to each message).
>
> By having CashUtil in the GnuCash CVS tree I'm hoping that the majority of
> translations will also be available for CashUtil. To install them separately
> and because the CLI has radically different formatting requirements, these
> will need to be separate po files.
>
>> So if these option strings are to
>> be displayed in a gnucash GUI dialog then they have to be translated by the
>> gnucash pot file as well.
>
> True. And CashUtil.
>
>> However, this only means that the msgid somehow
>> have to appear in the gnucash pot file
>
> Easily done now that the strings are in the C files in the one source tree
> that will eventually provide both GnuCash-GUI and CashUtil.
>
> --
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
>



-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available