Because Japanese doesn't have spaces, I've noticed a lot of posters have had trouble bolding individual words in sentences (myself included). See this answer for an example: http://japanese.stackexchange.com/questions/329/passive-transitive-verb-vs-intransitive-verb-vs/640#640 (not to pick on istrasci).

One of the issues is that the bolding appears correct in the preview pane, but not in the actual post. For example, 学生は**日本語**を教わった appears as 学生は日本語を教わった in the preview pane but 学生は*日本語*を教わった in the actual post.

Is this a bug with the preview panel that should be fixed, or should we develop a workaround as a community?

share
    
this isn't a bug to tied to a specific browser right? –  Mark Hosang Jun 6 '11 at 0:43
    
Bug is discussed in this meta stackoverflow question. –  Mechanical snail Aug 18 '11 at 20:52
1  
See meta.stackexchange.com/questions/240354/… for an update. –  balpha Oct 1 at 16:18

3 Answers 3

The preview and the final version will look identical from the next build of the site (a few hours at most). Unlike the final server-side rendering, browsers don't handle characters outside the A-Z range correctly, so I had to work around this.

So this case will not look like it's working when in fact upon submission of the question or answer, it does not actually work. This is the most important part, which is why I'm tagging this bug report as .

However, I'm very aware that there's another issue here, which is the "Japanese doesn't have spaces" parts, combine with Markdown's reliance on, well, spaces; not just for bold/italic, but also other areas where spaces as word separators are relied upon, because Markdown was really created with English in mind.

Honestly, I do not have a good idea for this at the moment, so for the time being, the workaround will have to suffice.

This is now fixed as well; see Markdown change: Intra-word emphasis now works.

share
    
Couldn't (most of) the space issue be fixed by explicitly treating CJK characters as non-letters? Presumably, on the server side, that would require changing the letter-matching regexp to exclude them, but I don't see any obvious reason why that couldn't work. –  Ilmari Karonen Jun 3 at 0:42
    
@IlmariKaronen That wouldn't do any good, because then you couldn't do anything like bolding anymore, which in Markdown requires the presence of a letter. For example, simply put the order must be whitespace asterisk letter for the beginning asterisk to start an italicized section. –  balpha Jun 3 at 5:07
    
Really? Well what the %&@# is that good for? ;-) –  Ilmari Karonen Jun 3 at 5:13
    
@IlmariKaronen Hmm, you're indeed proving me wrong. I'll think about it. –  balpha Jun 3 at 6:14

The discrepancy between the preview and the actual result should be considered as a bug because it defeats the very purpose of the preview. They should match either way.

I see that you know this already, but a workaround to make a non-space-delimited part bold in a post is to use the HTML markup <b>…</b>.

share

I would argue it's a bug with the bold system because if you click the "B" on the little toolbar it adds the ** markers, and those aren't working correctly. So even though you clicked the bold button you aren't really getting bold.

share

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .