Re: Reworking Gnumeric's function translations
- From: Jody Goldberg <jody gnome org>
- To: Christian Rose <menthos gnome org>
- Cc: Christian Neumair <chris gnome-de org>, gnumeric-list gnome org,GNOME I18N List <gnome-i18n gnome org>
- Subject: Re: Reworking Gnumeric's function translations
- Date: Fri, 5 Mar 2004 10:32:25 -0500
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]