Re: Reworking Gnumeric's function translations



fre 2004-03-05 klockan 06.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") },

Hm, should the function name really be translated?


      { 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
    }

Wow! This splitup is what I always desperately longed for when
translating Gnumeric myself. Excellent suggestion! :-D

The splitup will help to focus on consistency in the original messages
as you point out, and it will also very much help improve consistency
for translators and the ability for translators to spot changes and do
the necessary updates for those. Since the messages are split up into
smaller segments, each of them very much similar to those of other
functions, it will also help the automatic reuse and fuzzymarking of
messages, so that translators can easily reuse translations, which will
reduce the current workload for translators dramatically.


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

Yes!


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

Yeah, it's not trivial for a translator to automatically realize that he
or she should use 2,5;3,14 instead of 2.5,3.14 in the argument examples
since the locale would use a decimal comma instead of a decimal point as
the radix character. Translating the decimal character and the seperator
only once, with the appropriate translator comment added at those
places, makes very much sense.

Thanks a lot for this suggestion! I'm sure all translators look forward
to this happening in Gnumeric.


Christian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]