Reworking Gnumeric's function translations

[Jody Goldberg <jody gnome org>]

On Wed, Mar 03, 2004 at 07:56:26PM +0100, Christian Neumair wrote:
> On Tue, 2004-03-02 at 20:26 +0100, Christian Neumair wrote:
>
> > I sat down and investigated different possibilites for improving the
> > function internationalization system.
>
> The attached patches do the following:
> - gnumeric-src-Fize.diff: change N_ to F_ calls where neccessary
> - gnumeric-bind.diff: bind gnumeric to new domain using correct charset
> - gnumeric-buildsys.diff: tell build system about new dir, add Makefile
> generation hack

This approach looks good and should be committed as soon as
cvs.gnome.org gets more space.  The makefile kludges are damn ugly,
but they are admittedly the same ugly as gtk.

Nice work.

The next step is to start working on the long discussed next
generation of function docs.

The goal is to go from

    N_("@FUNCTION=PRODUCT\n"
       "@SYNTAX=PRODUCT(value1, value2, ...)\n"

       "@DESCRIPTION="
       "PRODUCT returns the product of all the values and cells "
       "referenced in the argument list.\n\n"
       "* This function is Excel compatible.  In particular, this means "
       "that if all cells are empty, the result will be 0.\n"
       "\n"
       "@EXAMPLES=\n"
       "PRODUCT(2,5,9) equals 90.\n"
       "\n"
       "@SEEALSO=SUM, COUNT, G_PRODUCT")

to something like
    {
        /* will we need a prefix on the function names eg NAME:PRODUCT ? */
        { FUNC_NAME,            F_("PRODUCT") },
        { FUNC_ARG,             F_("value1:values, strings, arrays, or ranges") },
        { FUNC_DESCRIPTION,     F_("PRODUCT returns the product of all the values and cells "
                                   "referenced in the argument list.") },
        { FUNC_EXAMPLE,         F_("PRODUCT(2,5,9) equals 90." },
        FUNC_HELP_END
    }
    see_also { "SUM", "COUNT", "G_PRODUCT" }
    compatibility {
        { "MS Excel", F_("In particular, this means that if all cells are empty, the result will be 0.") },
        FUNC_COMPAT_END
    }

A couple of nuances here
    - The 'is foo compatible' can also be handled in the foo
      importer.
    - It will help drive us to standardise the argument names
    - A FUNC_EXAMPLE_SETUP will be very useful for things like the
      db functions.
    ? I don't like the notion of requiring translaters to translate
      the argument seperators in (2,5,9).  That should be handled
      automatically.  How would people feel about using something
      neutral like (2||5||9) ?

The hard part will be automating the map from the current layout
without losing the translations.  I suspect the way to do it is to
set up the help in parallel.  Then generate the new things with F_
and leave the old ones with N_.  We've already got some automation
to split out the cheesy-markup which will get us several pieces.

With luck, this sort of scheme will improve consistency, and
decrease the burden on translators

Suggestions or Comments ?