Bug 729886 - RFE: Making space in editor visible
Summary: RFE: Making space in editor visible
Alias: None
Product: Zanata
Classification: Retired
Component: Usability
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 2.0
Assignee: Patrick Huang
QA Contact: Ding-Yi Chen
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-11 06:58 UTC by Noriko Mizumoto
Modified: 2012-11-07 06:18 UTC (History)
3 users (show)

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 06:18:48 UTC

Attachments (Terms of Use)

Description Noriko Mizumoto 2011-08-11 06:58:17 UTC
It is useful for users if a space can be visible with dot.

Comment 1 Sean Flanigan 2011-08-11 07:06:06 UTC
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 07:20:33 UTC
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-26 01:04:57 UTC

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-29 02:11:59 UTC

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-29 02:57:45 UTC
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 04:33:23 UTC
Assigning to Scrum product owner for prioritisation.

Comment 7 Hedda Peters 2012-10-10 00:43:48 UTC
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-10 02:50:09 UTC
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 05:59:17 UTC
committed into master:

space is visible as a grey underscore bar.

Comment 10 Ding-Yi Chen 2012-10-11 23:38:02 UTC
VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121012-0031)

Comment 11 Ding-Yi Chen 2012-10-11 23:52:09 UTC
According to Sean, the white spaces will be better presented by dot for easy counting. Thus Reassigned.

Comment 12 Patrick Huang 2012-10-12 01:20:30 UTC
(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-16 02:09:23 UTC
VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121015-1310)

Comment 14 Sean Flanigan 2012-11-07 06:18:48 UTC
Fix released in Zanata 2.0.

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