Bug 729886

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)?

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.

Noriko, 

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?

Hedda,

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.

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.

Assigning to Scrum product owner for prioritisation.

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.

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.

https://groups.google.com/forum/?fromgroups=#!topic/codemirror/gYDYpKEANlA


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.

committed into master:
https://github.com/zanata/zanata/commit/16cb46b7f6153090a07b4ad9517f70acadfd104d

space is visible as a grey underscore bar.

VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121012-0031)

According to Sean, the white spaces will be better presented by dot for easy counting. Thus Reassigned.

(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.

VERIFIED with Zanata version 1.8.0-SNAPSHOT (20121015-1310)

Fix released in Zanata 2.0.