Bug 729886 - RFE: Making space in editor visible
RFE: Making space in editor visible
Product: Zanata
Classification: Community
Component: Usability (Show other bugs)
Unspecified Unspecified
urgent Severity high
: ---
: 2.0
Assigned To: Patrick Huang
Ding-Yi Chen
Depends On:
  Show dependency treegraph
Reported: 2011-08-11 02:58 EDT by Noriko Mizumoto
Modified: 2012-11-07 01:18 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.8.0-SNAPSHOT (20121012-0031)
Doc Type: Enhancement
Doc Text:
Feature: Making space in editor visible to user. Reason: Invisible space may get neglected by user and cause error in software translation.To help identify leading and trailing space in text flow. Also helps to verify space is inserted in place correctly. Result (if any): Space is now visible as a grey underscore bar.
Story Points: 1
Clone Of:
Last Closed: 2012-11-07 01:18:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Noriko Mizumoto 2011-08-11 02:58:17 EDT
It is useful for users if a space can be visible with dot.
Comment 1 Sean Flanigan 2011-08-11 03:06:06 EDT
I think we will need to make this a user option, since not everyone will want to see visible dots all the time.  

For those who would use this feature, I imagine it's something you'd probably toggle on and off quite often?  (In which case the toggle button should probably be on-screen at all times.)

Where do you want the dots?  Throughout the table, just on the current row (source and target), or just in the active editor cell (target)?
Comment 2 Noriko Mizumoto 2011-08-11 03:20:33 EDT
Yup, agree with you, this should be a user option.

Once this feature turned on, a user usually won't change a setting and it stays on. So it would be enough that it can be set in Preference page or somewhere, and no need to have the toggle button on screen at all times. But this is just my opinion.

Prob, throughout the table.
Comment 3 Hedda Peters 2011-08-25 21:04:57 EDT

how exactly do you use this feature for Japanese?
Is your main concern avoiding double spaces? In that case a more elegant solution might be to only highlight double spaces as soon as Zanata detects them - nothing else, no dots for *every* space. A cleaner looking solution.
Lokalize does something similar (highlighting spaces at the end of a line I think)

Or do you also need to also see single spaces for Japanese Input Method?
Comment 4 Noriko Mizumoto 2011-08-28 22:11:59 EDT

Thanks for asking!
Unlike English sentences, typically Japanese sentences do not contain any space at all. For better rendering or avoiding the problem of no line feed, a space is deliberately inserted only at the beginning and the end of an English string (such as a product name) or a number (such as a version number). A space is also inserted after a punctuation mark for this reason. 

Visible dots for single spaces help us to ensure that a space is inserted where it is needed.
Comment 5 Hedda Peters 2011-08-28 22:57:45 EDT
Okay, thanks for clarifying Noriko!

In that case we should indeed stick to the original idea of having a simple dot for every space, as a user option.
Comment 6 Sean Flanigan 2011-09-07 00:33:23 EDT
Assigning to Scrum product owner for prioritisation.
Comment 7 Hedda Peters 2012-10-09 20:43:48 EDT
We ran into problems because of this feature missing:

A software translation project contained many, many strings with leading spaces. In the actual UI, there will be an additional text component appended to those strings. If we omit those leading spaces in our translation, the resulting text in the UI will have a space missing in between two words.

Currently these leading spaces are virtually invisible in Zanata. They therefore got omitted in the translation of this particular project, causing text in the UI to be displayed wrong (without a space between two words).

We urgently need to have leading/trailing spaces always highlighted (no user option), and normal spaces indicated by a dot (maybe as a user option)

I changed priority and severity to urgent/high.
Comment 8 Sean Flanigan 2012-10-09 22:50:09 EDT
Patrick, can you see if CodeMirror can do something easy to make the whitespace visible, preferably for 2.0?

Even if we can't distinguish between leading/trailling space and other space, it shouldn't be too difficult to show all space.


Hedda, you might also like to put in a request for an enhancement to the newline validator - perhaps it should be checking for any leading/trailling whitespace?  (Or it could be another validator.)  Someone should probably check whether "msgfmt -c" detects these whitespace errors.
Comment 9 Patrick Huang 2012-10-10 01:59:17 EDT
committed into master:

space is visible as a grey underscore bar.
Comment 10 Ding-Yi Chen 2012-10-11 19:38:02 EDT
VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121012-0031)
Comment 11 Ding-Yi Chen 2012-10-11 19:52:09 EDT
According to Sean, the white spaces will be better presented by dot for easy counting. Thus Reassigned.
Comment 12 Patrick Huang 2012-10-11 21:20:30 EDT
(In reply to comment #11)
> According to Sean, the white spaces will be better presented by dot for easy
> counting. Thus Reassigned.
Discussed with Sean, we can not (no perfect solution) make every individual space appearing as a dot. We will use current implementation as is.
Comment 13 Ding-Yi Chen 2012-10-15 22:09:23 EDT
VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121015-1310)
Comment 14 Sean Flanigan 2012-11-07 01:18:48 EST
Fix released in Zanata 2.0.

Note You need to log in before you can comment on or make changes to this bug.