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]