After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 115457 - Middle dot appears in msgstr (and gets saved!)
Middle dot appears in msgstr (and gets saved!)
Status: VERIFIED FIXED
Product: gtranslator
Classification: Other
Component: Interface
HEAD
Other All
: High major
: 1.0
Assigned To: Ross Golder
Fatih Demir
: 115851 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-06-18 14:54 UTC by Abel Cheung
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Abel Cheung 2003-06-18 14:54:52 UTC
In msgstr, whenever space is typed, middle dot will appear in msgstr in the
actual saved file. Conversely, if one intentionally type middle dot into
msgstr, then gtranslator will convert it into space when saving. This is
quite counter-intuitive.
Comment 1 Fatih Demir 2003-06-18 19:11:01 UTC
This bug is really present, set the bits accordingly - I think it has
got to with our beloved old and stupid conversion routines between the
middle dot and the space on the GUI side of things therefore this is a
bug for the Interface component.

Maybe with the new buffer system of Gtk+ 2.x one could set the space
char easily per se to a middle dot and then get Gtk+ 2.x around handling
all that for us easily; would this be possible?! Ross?
Comment 2 Ross Golder 2003-06-22 12:09:42 UTC
How come we need a 'gtranslator_utils_invert_dot' to add/remove the dot?

There's possibly a good explanation for this feature, but I can't
figure it out myself.

I can see why this occurs, as the call that 'undots' currently resides
in a block of code that is #ifdef NOT_PORTED. The function itself
works fine.

If there's a good reason for it, then we need to work out exactly
where this call needs to be used (on file loading/saving, or on GUI
input/output).
Comment 3 Fatih Demir 2003-06-22 16:34:15 UTC
It's needed to indicate the free space to the translator, just a display
feature with no background in the parsing etc. code should be only done
in the GUI displaying, editing and saving to GtrMsg code.

Was just a visual feature as desired by many translators previously.

_Sorry, but almost no time therefore just short excerpt of stuff.
Comment 4 Ross Golder 2003-06-22 17:13:36 UTC
No problem. If it was previously desired by many translators, I will
try to fix it up.
Comment 5 Abel Cheung 2003-06-26 17:47:08 UTC
I just wonder, if we could use different background color to show the
msgid and msgstr (including spaces), instead of using middle dot?
middle dot is good for showing spaces, but somehow I find it
disturbing for my eyes :-)
Comment 6 Ross Golder 2003-06-26 18:16:45 UTC
It'd help if I knew _why_ these people want to be able to display a
dot instead of a space. I can appreciate why it would be required in a
word processor, or other 'wysiwyg' application to differentiate
content and layout. I use this feature in word processors, but I still
can't see it's purpose in gtranslator. Can anyone enlighten me?
Comment 7 Ross Golder 2003-06-30 23:26:10 UTC
Is this still present in CVS HEAD?  I thought I could reproduce it
last week, but now I cannot.
Comment 8 Ross Golder 2003-07-05 13:10:13 UTC
I can't get gtranslator to save with the dots in. Can this be 
reproduced with CVS HEAD?

--
Ross
Comment 9 Fatih Demir 2003-07-05 21:21:29 UTC
Well, it seems to be reproducable within gtranslator: you'Ve got the
msgstr "(C)·1999·The·Free·Software·Foundation" in normal text view. If
you do now enter 2-3 spaces between the The and Free, then the text
looks like "(C)·1999·The   ·Free·Software·Foundation" and in the saved
file "(C) 1999 The··· Free Software Foundation" - hmmm, is this ok?

I guess not or? The case with the intentionally inserted middle dots ·
I get same msgstr as "(C) 1999 The··· Free Software Foundation      "

Hmm, I would say the problem still persists and there's a problem with
the dot inversion functions....
Comment 10 Ross Golder 2003-07-07 11:29:16 UTC
I can see it now. I think it's because when the user hits 'space' in
the translated textview, it goes it as a space, despite the fact that
the existing spaces are dots.

When the 'invert_dots' is called, it inverts the dots to spaces and
spaces to dots.

The textview should be hijacked so that spaces are input as dots. I
probably removed a bit of code (or didn't route a signal properly)
that introduced this bug.
Comment 11 Abel Cheung 2003-07-08 12:37:35 UTC
Confirmed, this problem still exists, depending on the preference; if
the special char option is turned on, then middle dots will be saved
into po file. If the option is off, then spaces are saved properly
into po file.

But... wait. What's the desired behavior for this option?

1. Both msgid and msgstr box shows middle dot
2. Only msgid box shows middle dot

Besides, here is what I mean by background highlighting:
http://deaddog.org/~maddog/screenshot/gtranslator-background-highlight.png
This is just an illustration, I have just added red background tag to
the text buffer, nothing more. Notice that extra spaces at the end of
msgstr entry is highlighted with red color. Is something like this
possible?
Comment 12 Alessio Dessi 2003-07-09 07:45:50 UTC
showing spaces with dot is useful because it is easy to see if a wrong
amount of space are inserted ... especially at the beginning of the
string. Sometime the string is indented using spaces and if you have
multiple sentences seeing the points works very well detecting the
misalinement.
Comment 13 Alessio Dessi 2003-07-09 07:55:44 UTC
another problem here around is that that I have described in the bug
#115851 every time you split a string, an extra space is added.

if you have 

msgstr ""
""
""

the resulting string loaded and after saved by gtranslator wil be 
msgstr "   "

RIP dog asked me to close the previous bug ... but dunno if is better
to leave it open for this one. let me know

Comment 14 Fatih Demir 2003-07-21 21:44:42 UTC
*** Bug 115851 has been marked as a duplicate of this bug. ***
Comment 15 Ross Golder 2003-07-21 22:53:30 UTC
OK, patch in CVS that should deal with this. Only basic testing done
(it's late), so please test and close this report if it's sorted.

--
Ross
Comment 16 Fatih Demir 2003-07-21 23:33:39 UTC
It's fixed now and works really like desired - thanks very much2Ross for the nightly
action :-)