GNOME Bugzilla – Bug 381564
Localize all function names
Last modified: 2018-05-22 13:18:39 UTC
The attached patch is hopefully a large step towards correctly localized functions. It adds localization caps to gnumeric expression serialization routines, assigns all function-related strings to the "gnumeric-functions" package. I also tried to ensure that all backend-related functions don't use translation (i.e. storage-related), while all user input parsers should support localized function names, and all user-output should be localized. Review appreciated. TODO * Do throughout testing * Support localized output in string-to-columns (STF) * Port all functions to a sane GnmFuncHelp layout * Correct po/POTFILES, po/POTFILES to include/exclude the relevant plugin and builtin function source files * Merge previous po/*.po translations to po-functions/*.po Because the last two items are Danilo's area of expertise, I'm CCing him. I'm also making this bug report depend on bug 312986, bug 312746 as they contain precious hints how we can improve the GnmFuncHelp descriptions.
Created attachment 77532 [details] [review] Proposed patch
Note that the @@ -768,6 +817,7 @@ gnm_func_add_placeholder (Workbook *scop part should be removed, it is a relict of previous experiments.
great job, but it breaks excel plugin: ms-excel-read.c:249: error: too few arguments to function 'gnm_expr_top_as_string'
Hmm, not fully functionnal. If I type =somme(A1:A3) the expression is rejected, but if I type =sum(A1:A3), things are ok. Now the expression appears as =somme(A1:A3) in the formula entry! If I edit them, I must replace the localized name by the C locale name before validation.
Created attachment 77540 [details] [review] Proposed patch #2 Good catch. The new variant of the patch also installs the localized symbol in gnm_func_add() and not just its stub variant, and fixes the remainder of the plugins that didn't adapt to the new expr API. It also removes the fragment mentioned in patch 2.
Great, it works fine now.
Ping.
It's on the radar.
Created attachment 147734 [details] [review] Updated patch Previous patch did not apply anymore. This one has not been thoroughly tested, just chacked that it compiled and chacked with one translated function in a gnumeric file (the function name is not translated in the file, just on screen).
I don't like translation of functions. English names usually are more convenient to use (e.g., they match with function names used in C and other programming languages). I think translation of function names should be optional
A problem similar to bug 633140 is going to show here.
> I don't like translation of functions. English names usually are more convenient to use I just like switching layout to type function... not.
Comment on attachment 147734 [details] [review] Updated patch 1. We already have a translation domain for functions. 2. Function examples should, by and large, not be translated. When untranslated, we parse in C locale and unparse if the proper locale. 3. Whether the gui should be translated should be in the Gnmconventions, not extra flags all over the place. [Done] 4. We don't want this unconditionally on.
That should have read "3. Whether function names in the gui..." Note, that steps 1+2 makes 95%+ of the patch unnecessary as well as 99% of the extra work for translators.
HEAD can tentatively do with when the magic GNM_LOCAL_FUNCS=1 is set. There are probably lots of bugs.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/67.