[Test] Changes newsteaser attribute to newsteaser class #1097
@max.mehl this PR goes to test to see if the changes are working. It looks dangerous since so many files are changed.
Thanks. I will merge master into test first to resolve all these conflicts
A few questions:
- Can I rebase on test and merge?
- Did you check whether these files were actually up-to-date translations? We should be careful not to touch outdated translations.
Can I rebase on test and merge?
Did you check whether these files were actually up-to-date translations? We should be careful not to touch outdated translations.
I didn't and now the system would say it's up to date because the change date is the same - right? We need the logical "version" system.. I have no clue how to check this in a reasonable way for all of the files.
I didn’t and now the system would say it’s up to date because the change date is the same - right? We need the logical “version” system.. I have no clue how to check this in a reasonable way for all of the files.
Yes, exactly, that's how the systems works. I agree that a version system, cleverly integrated in different workflows and well-communicated, may solve such issues. However, we would have to think of a way to handle old files, and those who already are outdated.
For a method to only change files which are up-to-date, see #1092
This becomes relevant as soon as we've adapted the version tag as discussed on web@.
As we have not yet applied this (and have to resolve all the conflicts anyway), let me throw in the idea of removing the "newsteaser" attribute/class completely and define that the first paragraph of the news entry is always the newsteaser - which is, AFAICT, a hard rule of how the attribute is used currently.
Makes sense to me. However, we have to check some XSL files that make use of this class. For instance, the logic behind the excerpts for the share buttons and some meta tags uses this.
While at it, should we also review whether we still need the id
introduction which is used for newer articles? The difference is that some introductions span multiple paragraphs, so this might be trickier.
I think the explicit definition of which paragraphs form the introduction is still required. Whether it should be an id= or a class= might be matter for discussion, but I guess that would be a different issue.
I certainly agree that if we remove the
newsteaser completely, all of its usage must be replaced by selecting the first paragraph of the news item.
OK, let's start with that and deal with the article ideas later :)
My assumption that the first paragraph is always the newsteaser is wrong. See for example https://fsfe.org/news/2009/news-20090120-02.en.html
So the complete removal of the newsteaser marker is out of discussion.
Now I am somewhat torn between
id="newsteaser". Since the purpose of the marker is to exactly identify a single element for several purposes, and the visual presentation is only one of these purposes, I'd actually lean more towards
id="newsteaser". What do others think?
I think a newsteaser is always the first paragraph, and would consider anything else (like the article you mentioned) a bug.
In the linked article, this is rather being used as a way to make the text bold rather than a teaser to the full news item.
Would you think that this is such a hard rule that we should enforce it technically? What would we do with old news items (still visible in the news archive) where this rule isn't followed?
We also have news items like https://fsfe.org/news/2008/news-20081215-01.en.html where forcing the first paragraph to be the newsteaser would not work very well at all.
I have meanwhile come to the contrary result: that technically we should not make any assumptions neither about the position of the newsteaser within the article, nor about the number of paragraphs it consists of. With a class="newsteaser" we leave all options open, but on the other hand it does not stop us from following our own rules and preferences if we want.
@max.mehl and everybody else, please let me know what you think.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?