720228 - including a template adds unnecessary space to template

Status: RESOLVED WONTFIX

(support.mozilla.org :: Knowledge Base Software, task, P3)

Description

[Kadir Topal [:atopal]]

When you include a template in an article that template is automatically appended with a space character for no apparent reason. From the source code it looks like we append templates with a line break. In any case, a following punctuation mark is preceded by a space character, which is wrong in many languages. 

Please remove that space.

Comment 1

[Ricky Rosario [:rrosario, :r1cky]]

Moving all 2012Q1 bugs to Future.

Comment 3

[Ton [:Tonnes]]

At the time of reporting bug 852275 and possibly this bug, this was a space issue allright, though Kadir referred to a line break insertion above (though this may be a line break versus carriage return issue). Anyway, the problem was a visible space until recently, but recent code changes to Sumo now appear to have changed this into a clear line break issue allright, as end stops now appear on a next line, making it a little bit worse than before.

Example: https://support.mozilla.org/en-US/kb/unable-install-add-ons-or-extensions - see the optionsPreferences line right after "To add the site to the trusted sites list:".

Comment 4

[Verdi [:verdi] Best to slack me]

Gah! I saw this the other day and wondered what was going on. Thanks for looking into it.

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ton from comment #3)
> Example:
> https://support.mozilla.org/en-US/kb/unable-install-add-ons-or-extensions -
> see the optionsPreferences line right after "To add the site to the trusted
> sites list:".

As far as I can tell, this is a content issue combined with a limitation of what we can with showfor.

if you look at the markup, you have two divs for showfor then a period outside the div. This period is forced to a new line, because that's how HTML works:

<li>
<div class="for" data-for="not fx29"><!-- content in here --></div>
<div class="for" data-for="fx29"><!-- content in here --></div>.
</li>

If you remove that last period, everything is good: http://cl.ly/image/0c2m3l2C1v3E

I'll submit a new revision for that.

Comment 6

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Kadir Topal [:atopal] from comment #0)
> When you include a template in an article that template is automatically
> appended with a space character for no apparent reason. From the source code
> it looks like we append templates with a line break. In any case, a
> following punctuation mark is preceded by a space character, which is wrong
> in many languages. 
> 
> Please remove that space.

Can you provide examples of this? or STR?

Comment 7

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #5)
> If you remove that last period, everything is good:
> http://cl.ly/image/0c2m3l2C1v3E

BTW, if you want the period back, you need to include inside the template and inside each showfor block

Comment 8

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Kadir Topal [:atopal] from comment #0)
> When you include a template in an article that template is automatically
> appended with a space character for no apparent reason. From the source code
> it looks like we append templates with a line break.

Looking at the example article provided in comment 3... If you do a View Source for the relevant section, you'll notice that the period that followed the template is right after the closing div of the template without any white-space:

<li> <div class="for" data-for="not fx29"><!-- I delete a bunch of content --></div>.
</li>


Given that, I am closing as WFM.

The issues that are happening are probably related to limitations of how we can include templates and how to use showfor within them.

Comment 9

[Kadir Topal [:atopal]]

Michael, does this work for you?

Comment 10

[Ricky Rosario [:rrosario, :r1cky]]

removing sprint metadata.

Comment 11

[Verdi [:verdi] Best to slack me]

(In reply to Kadir Topal [:atopal] from comment #9)
> Michael, does this work for you?

I'd characterize it more like, "I can live with that."

Comment 12

[Ton [:Tonnes]]

For info: I noticed that currently a space and a line break are inserted for Firefox articles, while it’s just a whitespace for TB articles. This seems odd, as their templates are about similar…

And, are you sure this should be a WFM? I mean, is it really impossible to fix? If so, I should get ready to fix a bunch of local articles adapting the template to include the period, and the same should happen for en-US. Of course, the 1 or 2 en-US articles that use the template preceding other text should be changed as well, if they still exist.

Comment 13

[Ton [:Tonnes]]

THere's a few questions remaining:

1) regarding the carriage return: the carriage return issue only shows up when using the optionsprefernces template. When using CloseOptionspreferences, only a space is added. Not usre if it’s worth investigating that?

2) At this time I think, not sure, it seems there are no active articles having occurrences of the OptionsPreferences template where they preceed other text within a sentence. As this bug concerns a general issue, all periods current versions shoulld have new revisions eliminating the periods and both the templates should include them. What action is required?

Comment 14

[Ton [:Tonnes]]

See https://support.mozilla.org/en-US/kb/Template%3Aoptionspreferences/discuss/2124 for discussion about steps still needed to be taken.

Comment 15

[Ton [:Tonnes]]

Meanwhile all KB artciles have been checked for (close)optionspreferences templates instances and stripped from their succeeding end stops in order to have them diplayed as they should.

Nevertheless and as asked above, I’d still like to know what causes the additonal line feed (/carriage return) in some cases, like occurred with the optionsPreferences tempate only, as we keep bumping in to this when using other templates calls such as closeFirefox or DisableHWAflash. Ricky, any idea where this line feed comes from and how to prevent it? Or is this simply unpredictable?

Comment 16

[Joni Chan]

While we've made some revisions to manually work around this issue (i.e. moving the template so it's not at the end of the sentence), it's difficult to remember to keep doing that. We'd like to fix this space problem so we can use the templates without having to remember workarounds. Re-opening this bug.

Comment 17

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

p3 seems right, this is super annoying but we have other higher priority bugs to fix