Bug 683881

It seems the translation uses characters not supported by the font.

Can we go for a different font?  Do we have the reported string actually in our yast messages or is this somehow inherited from glibc?  Please, type in the message here, then I could grep for it.

I bet it's inherited, since there's only a placeholder in yast message. It is in "base" module:
msgid "%1 (on average %2)"
msgstr "%1 (среднее %2)"

Thanks.  SO it is either a font or a yast/glibc problem.  I've no idea how to fix this.  Takashi, can you please help with it?

I could add that this appears only in numbers, not in other messages.

Judging from the screen shot, a bogus glyph is shown in the thousands separator.
What shows the following command in your system?

    % LANG=ru_RU printf "%'02.f" 123456.78 | hexdump -C

On mine, it's like:
    00000000  31 32 33 a0 34 35 36 2c  37 38                    |123.456,78|
    0000000a

That is, the thousands separator is 0xa0.

Seems that you need to run LANG=ru_RU.UTF-8.  Otherwise the non-breaking space isn't coverted to UTF-8.  With ru_RU.UTF-8, the separator becomes 0xc2 0xa0.

If this is correct, the next step is to check whether this character can be shown properly with YaST / Qt.

Takashi, my output is somewhat glitchy comparing to yours.
Actual command gives "invalid number" error:
minton@mintonlaptop:~> LANG=ru_RU printf "%'02.f" 123456.78 | hexdump -C
bash: printf: 123456.78: недопустимое число
00000000  30 30                                             |00|
00000002

Without decimal part output gives correct separator:
minton@mintonlaptop:~> LANG=ru_RU printf "%'02.f" 123456 | hexdump -C
00000000  31 32 33 c2 a0 34 35 36                           |123..456|
00000008

With russian decimal separator (we have comma instead of dot) it accepts a rounded number:
minton@mintonlaptop:~> LANG=ru_RU printf "%'02.f" 123456,78 | hexdump -C
00000000  31 32 33 c2 a0 34 35 37                           |123..457|
00000008

Using ru_RU.UTF-8 does not change anything.

If you are already running in the Russian locale, LANG=xxx isn't needed.  So, the actual thousands separator is a NBSP and 0xc2 0xa0 is the correct UTF-8 sequence for it.

That is, I see no problem in glibc, so far, supposing YaST shows the number with the printf format above.

A possible bug would be that YaST processes the printf above in a different encoding than UTF-8, then showing it as UTF-8 (or vice versa).

Please check whether a string with NBSP can be displayed properly in YaST in Russian locale.
If this works, it means that font and Qt are OK.  If not, check how the number is formatted in YaST.

Anyway, reassigning back to YaST guys.  I'm no i18n expert after all :)

Created attachment 424882 [details]
NBSP is displayed just fine in qt yast

I specifically modified and recompiled translations to test NBSP displaying itself. Edits are marked with red arrows. So QT and font are OK, its either yast or libzypp issue.

Arvin pointed the upstream bugzilla:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16006

And the old entry for novell bug 573692.

Actually, printf() works on 11.4 with NBSP and UTF-8, but C++ iostream doesn't work.
Is this the problem, supposing YaST uses C++?   If my guess is right, a workaround would be to use printf() explicitly for the formatting.

Only with C++ iostreams is it possible to set the locale without
affecting the global locale (esp. in a threaded environment).

And AFAIR we don't want to change to global locale for numeric output
since it can cause trouble.

See also the original bug #460094 leading to use of iostream.

OK, then the only chance is to work around it somehow (replacing 0xc2 with 0xc2 0xa0 in-place) or finally to fix libstdc++ for this long-standing (almost 7 years old!) bug...

I meant a quick-n-dirty patch like below...

Created attachment 425343 [details]
Fix patch (untested!)

I built packages containing the patch from comment 16:

http://download.opensuse.org/repositories/home:/tgoettlicher:/Factory/openSUSE_11.4/i586/yast2-core-2.20.0-3.1.i586.rpm

http://download.opensuse.org/repositories/home:/tgoettlicher:/Factory/openSUSE_11.4/x86_64/yast2-core-2.20.0-3.1.x86_64.rpm

Ilya, could you please test if it solves the bug?

Ilya, any news?

No, the patch does not work. Still the same incorrect characters.

Thomas, are you sure that the package in comment 17 includes any relevant fix?  I don't see it in the source.

(In reply to comment #20)
> Thomas, are you sure that the package in comment 17 includes any relevant fix? 
> I don't see it in the source.
Sorry, my bad. 

The patch is included in:
http://download.opensuse.org/repositories/home:/tgoettlicher:/Factory/openSUSE_11.4/i586/yast2-core-2.21.0-14.1.i586.rpm

http://download.opensuse.org/repositories/home:/tgoettlicher:/Factory/openSUSE_11.4/x86_64/yast2-core-2.21.0-14.1.x86_64.rpm

Could you please test?

Ilya, have you tested the fix yet?

I am not 100% sure but probably this has been fixed by the patch.

Created attachment 431784 [details]
Patch

Martin, could you please review and apply the appended patch to yast2-core? Thank you.

Well, that is a fine example of an ugly hack ;-)

But thanks for pointing out the upstream bug. I took the hint and used wide characters for a cleaner fix.

SVN: http://svn.opensuse.org/viewvc/yast?view=revision&revision=64129
RPM: yast2-core-2.21.2
OBS: https://build.opensuse.org/request/show/71744

*** Bug 536472 has been marked as a duplicate of this bug. ***