Re: Reworking Gnumeric's function translations

[Jan Morén <jan moren lucs lu se>]

fre 2004-03-05 klockan 14.12 skrev Jody Goldberg:

> 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 ?

Nice idea. 

A few comments, though: First, you will likely want to have a pretty
flexible format regarding the components of a function entry; function
descriptions can have from one (short) paragraph to several, with
differing structure, so you should probably allow arbitrary numbers of
FUNC_DESCRIPTION fields. Same thing goes for FUNC_EXAMPLE, of course.

Second, we really need this to preserve local ordering of these text
fragments for the translation. All pieces of text describing one
function should end up next to each other (in the right order) in the
.po files. Keeping a consistent vocabulary over an application as large
and as specialized as Gnumeric is a bit of a challenge already, and
having pieces of a function description floating around freely would not
improve matters.

A small suggestion would be to add a FUNC_BULLET field as one type of
description paragraph:

...
{ FUNC_BULLET, F_("If x<0, MOGRIFY returns #VALUE!") },
{ FUNC_BULLET, F_("If y="xyzzy", MOGRIFY will silently kill Gnumeric")
},
...

This kind of description is so common, it really deserves getting its
own formatting support.

_______________________________________________
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://lists.gnome.org/mailman/listinfo/gnome-i18n
-- 
 
Trust the Computer. The Computer is your friend.
 
Tel.    +46-046 222 8588             Dr. Janne Morén (mr)
Home:   +46-046 211 4973             Dept. of Cognitive Science
Fax:    +46-046 222 9758             Kungshuset, Lund
                                     S-222 22 Lund, Sweden