Missing space in formatting of percents in Calc

l10n
#21

Hi,

Hi,

So I did this for our locales that match
http://www.unicode.org/cldr/charts/29/by_type/numbers.number_formatting_patterns.html#17acd127f9139476

bas· ·be· ·br· ·ce· ·cs· ·cu· ·da· ·de· ·dsb· ·dua· ·en_AT· ·en_DE·
·en_DK· ·en_FI· ·en_SE· ·es· ·fi· ·fo· ·fr· ·gsw· ·hsb· ·ka· ·kl· ·ksh·
·lb· ·lt· ·nb· ·nn· ·qu· ·rm· ·rn· ·ro· ·ru· ·se· ·sk· ·sv· ·tk· ·zgh·

Revert it for ru (Russian), please.
We do not use space between number and "%". It may be an half space
but not nbsp.

http://orfogrammka.ru/типографика/знаки_номер_процент_параграф_градус_с_пробелом/

#22

Hi Serg,

Revert it for ru (Russian), please.
We do not use space between number and "%". It may be an half space
but not nbsp.

I can replace it with a U+202F NARROW NO-BREAK SPACE, or would Russian
speakers prefer no space at all like it was before?

  Eike

#23

*Safer* to have no space there at all, and for Belarusian, too.

The rules of hair splitting :)) require the narrow space before the units, indeed, but I don't think there are actually many fonts around containing the *narrow* U+202F (e.g., Times New Roman has regular width blank there).

Anyway, programs neither help with entering the glyph, nor highlight its non-breakability.

LibreOffice comes to mind :))

-Yury

P.S. Quite the same as it's with abbreviations of names and patronymics, which require narrow non-breaking spaces 'by the book' -- 'A._A. Ivanov', but for the actual use on computer are sub-standardised to be used with no space -- 'A.A. Ivanov'

#24

Hi,

I can replace it with a U+202F NARROW NO-BREAK SPACE, or would Russian
speakers prefer no space at all like it was before?

No space at all, please.

#25

Hi Yury,

*Safer* to have no space there at all, and for Belarusian, too.

The rules of hair splitting :)) require the narrow space before the units,
indeed, but I don't think there are actually many fonts around containing
the *narrow* U+202F (e.g., Times New Roman has regular width blank there).

I don't know, I don't use that one, all fonts I use have it, even the
terminal font :wink: which then as it is a monospace font of course
displays a normal width non-break space.

Anyway, programs neither help with entering the glyph, nor highlight its
non-breakability.

It's for display purposes only anyway, you don't have to enter a blank
when entering percentage values.

However, I'll remove it from ru-RU and be-BY.

  Eike

#26

*Safer* to have no space there at all, and for Belarusian, too.

...

Anyway, programs neither help with entering the glyph, nor highlight its
non-breakability.

It's for display purposes only anyway, you don't have to enter a blank
when entering percentage values.

Right, and it's exactly the issue -- in most of the 'real world' fonts the U+202F isn't actually narrow (enough). And the redactors DO grumble. :slight_smile:

However, I'll remove it from ru-RU and be-BY.

Thanks, and thanks for thinking ahead, too, even if it was a teensy bit overmuch :slight_smile:

-Yury

#27

Hi,

please add a non-breaking space between number and percent sign for
Slovenian (sl), too.

Thanks, m.

#28

gd should have that too

Michael

Sgrìobh Martin Srebotnjak na leanas 14/06/2016 aig 12:36:

#29

And also for Icelandic (is), please.

Sveinn í Felli

Þann þri 14.jún 2016 11:36, skrifaði Martin Srebotnjak:

#30

Hi Martin,

please add a non-breaking space between number and percent sign for
Slovenian (sl), too.

Was already done with
https://cgit.freedesktop.org/libreoffice/core/commit/?id=d5146c0e3ca7459db4fdc3b348cec4012555ea35

  Eike

#31

Thanks.

I have another question. In Slovenian, this space is OK for literature,
texts, but not for formulas. Is there a way to differentiate where the rule
is applied in LO? Also, can a user toggle this rule (on/off)?
I will ask users to test RC1 and report back if it is too disrupting in
Calc etc.

Thanks, m.

#32

Hi Michael,

gd should have that too

Done with
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=cfc22e4614499de3987fcf4ca178e6349666c9af
on master and for 5-2 with
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=976377ef41b4911b7c0c19e3e7481d42f86b050a

  Eike

#33

Hi Sveinn,

And also for Icelandic (is), please.

Done with
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=cfc22e4614499de3987fcf4ca178e6349666c9af
on master and for 5-2 with
https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=976377ef41b4911b7c0c19e3e7481d42f86b050a

  Eike

#34

Hi Martin,

I have another question. In Slovenian, this space is OK for literature,
texts, but not for formulas. Is there a way to differentiate where the rule
is applied in LO?

No.

Also, can a user toggle this rule (on/off)?

No. S/he could only create a user-defined number format and use that
instead, but the default when entering a percent value into an
unformatted cell will always be the format from locale data.

  Eike

#35

OK then,

> Also, can a user toggle this rule (on/off)?

No. S/he could only create a user-defined number format and use that
instead, but the default when entering a percent value into an
unformatted cell will always be the format from locale data.

Is there any plan or rationale (also for other languages) to further
develop these rules to apply differently to different texts (i.e.
spreadsheets and text documents)?

I will push for a test period and really ask users to report back in time
to change this back latest with RC3. Is that feasible? RC2 is just too soon
to get a proper feedback. And I do not want a release to disrupt the way
that users work.

Also, does this mean that this is already in place/working with 5.2b2? If
so, I can ask Slovenian users to already try this out and report back.

Thanks, m.

#36

Hi Martin,

> > Also, can a user toggle this rule (on/off)?
> No. S/he could only create a user-defined number format and use that
> instead, but the default when entering a percent value into an
> unformatted cell will always be the format from locale data.

Is there any plan or rationale (also for other languages) to further
develop these rules to apply differently to different texts (i.e.
spreadsheets and text documents)?

No. Also, usually formats are independent of document types.

I will push for a test period and really ask users to report back in time
to change this back latest with RC3. Is that feasible? RC2 is just too soon
to get a proper feedback. And I do not want a release to disrupt the way
that users work.

If we'll do RC3 ... and the time frame permits.

Also, does this mean that this is already in place/working with 5.2b2? If
so, I can ask Slovenian users to already try this out and report back.

Likely, the change went into 5-2 on June 6, the beta2 tag was on June 7.

And really, you should get the CLDR updated if the space is not to be
used. For i18n developers the CLDR is the authoritative resource when in
doubt.

  Eike

#37

Hello,

And really, you should get the CLDR updated if the space is not to be
used. For i18n developers the CLDR is the authoritative resource when in
doubt.

OK, the problem is, MSO is no following this rule, so potential users of LO
will get confused even though LO's is IMHO a better solution.

#38

Hi Martin,

> And really, you should get the CLDR updated if the space is not to be
> used. For i18n developers the CLDR is the authoritative resource when in
> doubt.

OK, the problem is, MSO is no following this rule, so potential users of LO
will get confused even though LO's is IMHO a better solution.

So, CLDR is correct and LO now is also, but MSO does not have the space?
Number formats are imported from existing MSO files, if that is the
concern. If the concern is that users are presented with a different
but correct default format, then, well, what can we do? Undo all
changes? I'd not be a friend of that, and likely others aren't either.

On a long term we might implement some user definable default formats,
but that's not in the near future.

  Eike