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 134089 - Non-translator-friendly strings of function description
Non-translator-friendly strings of function description
Status: RESOLVED DUPLICATE of bug 587156
Product: Gnumeric
Classification: Applications
Component: Documentation
git master
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 117655 125229 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-02-11 08:54 UTC by Funda Wang
Modified: 2009-06-27 22:21 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to plugins/fn-complex/functions.c (1.50 KB, patch)
2004-02-11 09:30 UTC, Funda Wang
none Details | Review

Description Funda Wang 2004-02-11 08:54:19 UTC
There are a lot of function descriptions. All of them are in the form of

"@FUNCTION=FUNCTION\n"
"@SYNTAX=FUNCTION(arg1,arg2...)\n"
"@DESCRIPTION=...\n"
"\n"
"args explaination.\n"
"\n"
"@EXAMPLES=..."
"\n"
"@SEEALSO=..."

Why not split the form out of the content? I'll provide an example to 
show how it will be from the translation's view.
Comment 1 Funda Wang 2004-02-11 09:30:34 UTC
Created attachment 24295 [details] [review]
Patch to plugins/fn-complex/functions.c
Comment 2 Funda Wang 2004-02-11 09:36:50 UTC
Sorry, I've reversed the order of the orginal file and the modified 
one. Lines marked with '-' should be the modified one.

Thus, the translatiors will only need to translate the actual 
content, rather the form itself. Of course, the better way is to 
introduce a new strings class/structure, which will generate 
descriptoins based on its members.

Please note, I've singled out "* This function is Excel 
compatible.", because it is commonly used by a lot of functions. The 
same applies to the sample data of financial functions.
Comment 3 Morten Welinder 2004-02-11 18:06:14 UTC
This has been known for a while and a proper solution is being
considered for the 1.3 series.
Comment 4 Funda Wang 2004-09-07 01:57:58 UTC
How is this going?
Comment 5 Jody Goldberg 2004-09-07 03:42:32 UTC
We've got a design but unfortunately it is too late in the cycle to implement it.
As soon as 1.4 ships we're going to start on the tools to migrate the current
translations into the new format.
Comment 6 Funda Wang 2005-05-31 06:37:54 UTC
It seems that the situation never changed.
Comment 7 Jody Goldberg 2005-05-31 13:55:13 UTC
Actually we've taken a big step towards fixing this.
There is now a design in place, and some of the functions have been converted.
Comment 8 Funda Wang 2005-10-15 15:17:32 UTC
what is the timeline scheduled for this change?
Comment 9 Jody Goldberg 2005-10-15 23:36:48 UTC
We're going to audit and transfer all of the function docs as soon as gnumeric
branches.  That should be some time this month.
Comment 10 Funda Wang 2006-05-21 06:56:47 UTC
Still the case in 1.7.0
Comment 11 Andreas J. Guelzow 2008-11-09 08:06:19 UTC
Well, it is really boring work to change all those descriptions, even with appropriate use of regular expressions. I have just committed changes to all the statistics functions. So at least we are on the right track. I will try toi find someone to change some more functions.
Comment 12 Andreas J. Guelzow 2008-11-09 08:08:52 UTC
*** Bug 125229 has been marked as a duplicate of this bug. ***
Comment 13 Andreas J. Guelzow 2009-06-24 09:35:24 UTC
*** Bug 117655 has been marked as a duplicate of this bug. ***
Comment 14 Andreas J. Guelzow 2009-06-27 22:21:07 UTC

*** This bug has been marked as a duplicate of 587156 ***