Issue 92056 - localize the separators in formula expressions
Summary: localize the separators in formula expressions
Status: ACCEPTED
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: DEV300m26
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on: 106959 107458
Blocks:
  Show dependency tree
 
Reported: 2008-07-23 20:53 UTC by kyoshida
Modified: 2013-07-30 02:47 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
screenshot of Formula options page (50.68 KB, image/png)
2008-12-12 06:12 UTC, kyoshida
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description kyoshida 2008-07-23 20:53:43 UTC
Make the parameter separator, and array column and row separators locale
dependent so that e.g. in the English locale they will be ',' ',' and ';'.
Comment 1 kyoshida 2008-07-23 21:03:50 UTC
started.
Comment 2 ooo 2008-11-20 19:53:20 UTC
When browsing the thread
http://lists.go-oo.org/pipermail/dev-go-oo.org/2008-November/000957.html
especially for the Russian locale
xlRowSeparator: :
as mentioned in
http://lists.go-oo.org/pipermail/dev-go-oo.org/2008-November/000965.html
I have serious doubts about the sanity of such feature, given that ':'
is also the range operator (or is even that different in a Russian Excel
localization?). We'd need special treatment of common operators when
within array constants in that case.

Of course the request to support ',' as the parameter separator makes
much sense, so does flexibility in decimal separator, and array
constants' row separator would also be nice. We will have to give up the
possibility to parse group separators within formula values. We should
ask ourself though to what extend we are willing to support some quirks
that different locales in Excel introduced and maybe changed between
Excel releases? Should we allow arbitrary configuration of the array
constants' row separator because expressions aren't possible anyway? Or
should there be the prerequisite that no separator shall clash with an
operator?

Anyway, we'll end up with configurable separators, to be defaulted to
whatever UX thinks would be right, current OOo or (Excel) locale
dependent. Plus we'd need either pointers in or locale dependent online
help if the latter. Sounds like a nightmare to me. YMMV.

My 0,02 €
Comment 3 kyoshida 2008-12-12 05:55:54 UTC
I believe, given all possible scenarios, providing a set of configurable
separators would make most sense.  We can't possibly emulate Excel's separators
in all locales, but we should at least cover major locales, leave the users an
option to change them if they don't like the default values.

The UI should impose some restrictions on what character can be used as
separators.  It's messy but possible.

In on-line help, we could probably just use the current set of separators, with
a pointer to the separator configuration.  It may become messy, but I think it's
the role of on-line help to supplement the feature but the feature should always
come first.  IOW, the on-line help itself should not limit what feature should
or should not be implemented.
Comment 4 kyoshida 2008-12-12 06:12:24 UTC
Created attachment 58760 [details]
screenshot of Formula options page
Comment 5 kyoshida 2008-12-12 06:13:54 UTC
I've made a new configuration option page - 'Formula' - to allocate more space
for this.  I've also moved the formula syntax option to this page, as I feel the
two options should be side-by-side.
Comment 6 ccheney 2009-02-04 13:51:24 UTC
The formula documentation needs to somehow reflect the new separators as well.
Comment 7 Rob Weir 2013-07-30 02:47:53 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.