After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 633140 - Trouble using localized constant names
Trouble using localized constant names
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Analytics
git master
Other Linux
: Normal normal
: ---
Assigned To: Morten Welinder
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2010-10-25 21:30 UTC by Andreas J. Guelzow
Modified: 2013-04-19 20:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Andreas J. Guelzow 2010-10-25 21:30:29 UTC
start Gnumeric in German locale
in A1:  =if(falsch;1,0)
in A2:  =if(false;1,0)

note that A1 has value 0 and A2 value #NAME?

save
quit
reopen the file in German locale

now A1 and A2 have both value 0 (since the "false" has been translated to "falsch")
Comment 1 Andreas J. Guelzow 2010-10-25 21:32:41 UTC
I think a solution would be to always accept FALSE and TRUE (and the untranslated errors) in addition to the translated strings (of course with preference to the translated once in case there ever is a conflict).
Comment 2 Morten Welinder 2010-10-25 22:13:08 UTC
See also bug 381564 -- localisation of function names.
Comment 3 Jean Bréfort 2010-10-26 08:44:34 UTC
Just check with oocalc, and it presents the same issue. xl doesn't, most probably because it stores the evaluated value, not only the formula.
Comment 4 Morten Welinder 2010-10-26 13:33:28 UTC
I would think xl would have the same problem if (1) you used an xml (==text)
format and (2) you hit recalculate (F9) on load.
Comment 5 Jean Bréfort 2010-10-26 13:50:01 UTC
May be, I can't test, no recent enough xl around.
Comment 6 Morten Welinder 2010-10-27 13:07:34 UTC
Partially fixed.  We have a function that tests whether a name is valid;
I made it check untranslated TRUE/FALSE too.

However, if in US-locale I defined a name "FALSCH" with a value of TRUE,
save that, and reload in DE-locale, then I am likely to see changes.
Comment 7 Morten Welinder 2013-04-19 20:20:19 UTC
This is as solved as it will ever be with text based formats like
.gnumeric and .odf

Re comment 6, the sheet actually loads right in DE locale.  Problems
only arise when you edit a cell using the name FALSCH.

"Don't do that".