Issue 106960

Arguments against this enhancement.

1) Your "looks very" nice.
The fact you added a smiley at the end tells me you will understand that your
argument is highly subjective and thus not an argument :)
I could say "it's ugly" without further detail: +1 + -1 =0

(BTW: I am native of country where the space - thin or not - IS the norm as 
thousand separator. So that one cannot accuse me of being biased when I advocate
against your proposal. ;) )

Now the real argumentation...

2) "separator can lead to confusion when (printed) documents are exchanged
between countries with different usages of commas and periods"

Here and in the rest of your motivation I see an attempt to say "this world with
many different - and sometimes even contradictory - languages, cultures and
usages makes exchanges complicated and might even lead to errors. Let's adopt a
common way of communicating, standardizing...".

<sigh> That's a big question I don't want to discuss here. I consider this also
as not a good argument because I tend to prefer culture heterogeneity to
technical ease of use. In other words, the machine has to adapt to the people,
not the contrary.

But ok, you speak about "optional" use... But there I ask myself: why should we
(software makers) respect locales and standards if we give the user the
possibility to break those standards?

3) Technical argumentation.

a) AFAIK the Unicode U+2009 character is not available in a majority of fonts
thus you would get 1000000 or maybe even 1?000?000 in some cases.

b) The Unicode U+2009 is a breaking space. Thus, you will get in some cases:
1 000<end of line>
000


Especially for the 2 last reasons I'd like to close this issue as WONTFIX.
Though, if you want, I'd like to invite you to discuss this further (and first
of all the motivation of your proposal) on discuss@ux.openoffice.org.

Closed

Reopened

Hello es,
I skip the first point and go directly to the real argumentation:

2) es wrote:
> "Here and in the rest of your motivation I see an attempt to say "this world ..."
You may see this point, but it is totally not mine. After all this is just a
feature request for one of the many office applications out there.

In the following points you are contradicting yourself IMHO:
> "In other words, the machine has to adapt to the people, not the contrary."
...
> "... why should we (software makers) respect locales and standards if we give
the user the
possibility to break those standards?"
Because giving not the possibility would, in fact, imply people have to adopt to
the "machine".

Also in 1) you mention your locale has spaces as thousands separators.
This fact (almost) makes the whole discussion obsolete, because this means OOo
should have/had this possibility already in the fist place! (In order to
maintain / not break locale standards.)

So, up to here I would say we both agree on the need of this feature (?).


3)
I really overlooked the fact that Thin Space (U+2009) is a breaking space,
however there are several solutions:
- Instead of the Thin Space the Narrow No-Break Space (U+202F) character could
be used.
- The Thin Space could be used in combination with two (each on a side) Word
Joiner (U+2060) characters.

I don't know how widespread these characters are, as per Wikipedia these
characters were introduced with Unicode 3.0 (in 1999) and Unicode 3.2 (in 2002),
respectively. So IMO chances are they will be more widespread in the (near?)
future (as OOo itself hopefully too).
On the other hand, since this feature will hopefully be optional, the user can
change the thousands separator any time, in case he is bound to an incompatible
font.

@famo:

I re-read your first and last comments and there's something I completly overlooked:
You have filed this issue to the "UI" component. So a very "visual" and general
stuff concerning most of the time the display and look&feel of OOo (dialogs,
toolbars, appearance...).

So now I don't understand your report anymore :(

Please mention very concrete occurrences of what you describe: where should what
look how when you do what?
(Ex:
- importing a csv in Calc - Dialog view and data insertion?
- inserting a formatted field in Writer?
- AutoCorrection in Writer tables
- ...?) :)

To your other comments I can give you an answer at rhetorical level even if I
missed the full content: :)

> In the following points you are contradicting yourself IMHO:...
>> "In other words, the machine has to adapt to the people, not the contrary."
...
>> "... why should we (software makers) respect locales and standards if we give
the user the
possibility to break those standards?"

No I don't :) Because with "standards" I didn't mean "computer standards" but
"locale standards" which pre-existed when the computer technology decided to
translate them - maybe with bugs? - for the machine.

I meant standards defined by country governments (so let's talk about "humans"),
not the interpretation of those made by non-native computer specialists.

Your request sounds to me right now like: "I want to use your grammar checker
but I want it not to mark 'he doesn't know *no*thing' as correct"...

-> contradiction

In other words: it sounds to me as if you want a software to give you the
opportunity to overrule human rules (grammar/decimal sign/thousand separator)
with your own (as person) needs. Am I wrong?


> Also in 1) you mention your locale has spaces as thousands separators.
> This fact (almost) makes the whole discussion obsolete, because this means OOo
> should have/had this possibility already in the fist place! (In order to
> maintain / not break locale standards.)

It does have! If you have the correct locale (while importing, in the UI... or
whatever... it depends of what you mean - "what, where, when"...)

Once again: please give concrete examples.

3) To your alternative proposals: we will discuss this further when we will have
first defined "what, where, when" :)



I'd like to stress followings:
- My "feeling" is (Just "feeling" because I know now I might not have fully
understood you) that your request is not an improvement but a regression.
- But the way you express it is worth of a discussion.
- That I should normally reassign to the general "requirements" pile where it
might remain untouched during decades...
- And that I'd like your proposal to be seriously analyzed before that term. :)

So once again: please expose this again on discuss@ux.openoffice.org.
There, you will get real time attention from very different people but all
committed in improving our software.

Sum up: this issue does not only depends on issue 106961, this is somehow a
duplicate of it.

If we give the user the opportunity to choose his own separator (issue 106961),
the UI will probably be an edit field.
The character can then be entered vie context menu - Special character.

With all drawbacks discussed here about U+2009 (breaking space, not broadly
supported) U+202F (not broadly supported) it sounds better not to complicate the
UI with predefined defaults (i.e. in a list box):
"',' Comma
'.' Point
' ' Narrow No-Break Space
' ' Thin Space
..."

... which is not directly understandable and would give most of the time broken
results.

Let's stuck to the summary of issue 106961 ("own liking") and let's not define
defaults.



*** This issue has been marked as a duplicate of 106961 ***

closed