Re: Reworking Gnumeric's function translations



On Fri, Mar 05, 2004 at 11:59:57AM +0100, Christian Rose wrote:
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?

Yes.  We will want to display localized names at some point.  What
we'll probably do is to provide a sample worksheet that calls every
function and request that translators find a copy of MS Excel in
their locale.
 
    ? 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, I'd forgotten about the decimal point.  It is important to
realize that translators _can't_ translate the seperators.  Those
are controlled by LC_NUMERIC/LC_MONETARY.  On further reflection it
may be better to move the examples into their own block so that we
could say
    examples[] = {
        { "2,5,9", F_("equals bobo"") },
        ...

On the positive side that would 
    - avoid translating the name of the function several times
    - force gnumeric to handle the localization of arguments.
    - It would not preclude locale specific examples.  I don't
      immediately see a reason to have them, but for the string
      functions it would be a nice touch.  We'd just need to be
      explicit with translators not to translate the seperators.

On the down side
    - It doesn't give translators much context for the results
    - It would generate even more code for the functions



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