Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

文章内容、格式清理 #597

Closed
XueningZhu opened this issue Jul 15, 2017 · 16 comments
Closed

文章内容、格式清理 #597

XueningZhu opened this issue Jul 15, 2017 · 16 comments
Assignees
Labels

Comments

@XueningZhu
Copy link
Contributor

XueningZhu commented Jul 15, 2017

对每个文章进行整容:

  1. 确认分类信息:请按照分类表中“分类”对应
  2. 确认标签信息:添加关键词信息,多多益善,在参考历史标签的基础上,确保概括全文主要信息
  3. 确认作者信息:作者+审稿+编辑,具体参考谢大示例:
    整容前:https://5969a93b424ef2014bfb9cbe--cosx.netlify.com/2017/05/random-number-generation/
    整容后:https://cosx.org/2017/05/random-number-generation/
  4. 确认短链接(参考上述链接)
  5. 确认文末版权信息
    ……(待添加)
@yihui yihui added the 主站 label Jul 18, 2017
@XueningZhu XueningZhu changed the title 文章清理内容 文章内容、格式清理 Jul 22, 2017
@XueningZhu
Copy link
Contributor Author

@fyears 请小黄重点关注一下。
已跟小黄同志说明,小黄会负责和把关文章格式方面的问题。 @yihui

@yihui
Copy link
Member

yihui commented Jul 22, 2017

哦耶。

@XueningZhu
Copy link
Contributor Author

@fyears 小黄同志,历史文章的格式问题修改规模有多大,辛苦评估一下哈,如果能多人并行就再拉几个小伙伴

@fyears
Copy link
Member

fyears commented Jul 23, 2017

主要是我在清理作者的时候,看到的一些问题 #669

  1. 采访稿(关键词“访谈”)里,受访人的个人介绍放到哪?(采访人就是 COS 的人啦)大部分是塞到正文的第一段,而且格式不统一:有些使用引用格式,有些使用 **重点** 格式,有些还写上”【编者按】“之类的。这个能怎么搞?目前我记忆中就yihui啊kouqiang啊yubin啊专门开了个 members.yaml 条目。
  2. 同理,转载稿的作者介绍如何处理?现在好像都是正文第一二段。
  3. 正文内的:编辑、审稿之类的我粗略清理了一次。这个也许能够自动化搜索正文关键词“编辑”“审稿””审阅“”翻译“”译者“”小编“”作者“再清理一次。。。(比如我刚才随手一找,居然看到我漏掉了的。。)
  4. 版权可以清理”敬告各位友媒...“可以清理,这个全文搜索一下,可以顺手做了。
  5. 原创的文章的版权声明没啥问题。翻译稿和转载稿的版权声明格式怎么做?现在的都是写在正文第一段或者最后一段。需要对 hugo 主题再加个 meta 信息,还是保持原样不动了?
  6. 系列文章需要统一格式吗?比如说(分别搜索以下关键词即可)每周精选(标签”每周精选“,五十多篇吧)、会议通知(标签”新闻通知“,八九十篇吧。。)、会议或沙龙纪要(四五十篇?)、狗熊会分析报告(有几篇,好像都是 xuening 你的。。)、访谈(四五十篇)

还有就是老生常谈的,什么中英文之间要空格(我个人习惯。。不过99.99%文章都是不空格的,随大流也可),什么时候用粗体字体、用斜体字体、代码左右用反撇号包着。什么时候用什么格式,比如说这篇的末尾小结,明明是正文,为啥要用引用格式捏。。

我个人意见:

  1. 首先是放眼未来,给上面标记了 1 2 3 4 的,都给一个”标准格式“,以后尽量按照标准格式来提交或编辑就好了(翻译稿、转载稿什么的作者信息放哪里、沙龙纪要的作者和正文如何写)。
  2. 回首过去,按不同系列的文章稍微清理一下即可。比如说,我认为,访谈稿比会议纪要更重要,毕竟会议纪要有时效性。
  3. 老生常谈的问题,随他去吧。。。全部清查一次也太不人道了。。。。见一个改一个呗。

以上。 20170723

@fyears
Copy link
Member

fyears commented Jul 23, 2017

哦,至于标签问题,我没什么好说的。私以为边师姐在搞:#609

我们这么多机器学习的,就不能机器学习一下 tags 吗?来一个最简单的 tf-idf 也可以啊!

@fyears
Copy link
Member

fyears commented Jul 23, 2017

噢!我明白了为什么会漏掉清理作者等。

因为按照 #663 的方法,我只找寻了所有 blogdown::count_yaml('author') 作者不对劲的文章。但是 author 字段没有问题而正文注明了审稿编辑等的文章,并没有找出来修改。

所以 @yihui#663 重开吧。。指点一个 blogdown 快速找寻正文关键词的方法。。。

@XueningZhu
Copy link
Contributor Author

@fyears 你来全权定吧,我没有多少建议,其中我建议受访人介绍放在开头、转载声明放在结尾。按照你说的,先清理重要的,具体系列怎么格式我建议你给定一个,然后以后都按照这个来。
你说的狗熊会分析我想搜索一下但是不知道为啥今天网络点了搜索之后没有反应……奔溃,但是应该不是我是作者,那是当时一些学生大作业。

@yihui
Copy link
Member

yihui commented Jul 23, 2017

@fyears 正文寻找关键词只能靠在文件夹下搜索,RStudio 里面 Ctrl/Command + Shift + F。至于这些规则什么的,如雪宁所说,你来决定吧。文章个人信息我的建议跟雪宁不同,因为有些作者的介绍比较长,放在开头会打扰阅读,不如看完文章之后再来八卦作者的个人信息,所以我还是建议放在文末。

@XueningZhu
Copy link
Contributor Author

@yihui @fyears 放在文末也行,原则是能读明白就行:) 请小黄同志来全权定,最重要是统一统一统一:)

@yihui
Copy link
Member

yihui commented Jul 24, 2017

对,统一统一统一!统一方便面!

@fyears
Copy link
Member

fyears commented Jul 30, 2017

呀,又一个周末过去了。。。。。罪过,罪过。。。

我看了一看,找了一找,按照个人审美定夺。姑妄言之,姑妄听之。

访谈

这个 堪称完美,我最喜欢这个版式

  1. 受访人的介绍写在第一段,除了名字粗体之外,使用普通自然段介绍即可。不用添加”【编者按】“等多余的说明(因为访谈稿的非对话内容总是编辑添加的,总不会是受访者按吧?)为啥写在前面?因为我们要知道受访人多牛逼才有兴趣看他们的访谈啊!
  2. 采访的背景、环境等写在对话之前。
  3. 对话形式中,采访人和受访人用粗体,然后冒号,然后普通字体的对话内容。
  4. 对话中插入较长的编者按或者其它注释的话(超过 20 个字?),我喜欢用脚注的形式标注。目的是为了不打断整个对话流的感觉。

当然了,万事皆有例外,比如说这个中间一大段”编者按“,这个本身就和下面采访的话题密切相连,似乎塞在脚注里的花又不太好😭没办法了,塞在正文中间吧。另外这个,显然就是每一个师兄师姐是一个独立的访谈嘛,我认为除了每个人的独立介绍不需要标注重点之外没有什么问题。

每周精选

这个这个选择一种呗。如果没有意见,那就随机选择的参照第一种吧。只要不要两种格式混杂就行。

  1. 分类作为大标题,每个条目写上第一自然段。
  2. 投稿人作为作者标注,而且在正文第一段写明是投稿人,而不是文内链接的作者,以免引起误会

翻译稿、转载稿

翻译稿、转载稿其实是一样的,都是衍生自别人的作品,所以这里归为一类。

  1. 原文作者写在 author 字段里。
  2. 译者啊、编辑等的名字,都写在 meta_extra 里。
  3. 版权,原文链接都写在原文第一自然段的前面使用粗体。
  4. 原文作者的简介也写在原文正文第一自然段的前面。

有一些我拿不准的, 就是比如说谁谁谁翻译,已经在 meta_extra 里标注了,还需要在开头的一大堆说明里再提一次吗?此外开头的一大堆版权、原文链接、原文作者简介用什么包起来?现在好像都是用引用符号包起来,以和真正的原文区别起来。我没有什么建议,因为我也不知道语法上该用啥。

其它

  1. 该是代码的内容,就用反撇号包起来!多行代码该标注编程语言的,就标注好!这个目测投稿的伙伴们很可能不注意的。格式参照 fenced code block。毕竟我们是一个代码网站。

  2. 同理,数学公式适当使用 LaTeX 符号标注。 (@yihui 现在的行内代码到底是怎么一个格式?要不要反撇号包住金钱号?)毕竟我们是一个统计和数学网站。

  3. “编辑”“审稿””审阅“”翻译“”译者“”小编“”作者“都塞到 meta_extra 里,不需要出现的,就不要出现在正文内容里了。大家深藏功与名?

  4. 我发现大家都在”滥用“引用符号,比如说编者按到底要不要用引用号?

> 大家都是:不知道用啥标注特殊区域文字 ,那就用引用符号吧。
> 看上去挺美观的。。。
> 到底怎么破?
  1. 没有特殊情况的话,版权声明不用写了,交给标准模板处理。转载、翻译的在原文正文前面标注好原文链接和版权情况。

  2. 中英文之间空格,英文字母和中文标点之间不用空格。这一点,是我的个人执念。实际执行起来,我认为只要一篇文章内统一就好了。。。

  3. 大小写:iOS、JavaScript、R、Python。这个也是个人执念。。之前文章的不要改了,太不人道了。

20170730

@Lchiffon
Copy link
Member

既然这样, 就先在这个issue里面high起来

  1. 审稿需要掌握的文章预览

    • 用github preview
    • 在成功部署之后点小绿勾
    • blogdown::server_site
    • 按照这个repo的流程使用COS Review预览工具
  2. 文件的位置与名称

    • 文件的位置需要注意, 一定要放在content/post 否则是无法成功发布文章的
    • 文件名需要按照date+slug+.md的形式完成, 缺了任何一个都会出错
    • 文件名中的date 需要与YAML的date 一致
    • 文件名中的 slug需要与YAML的slug一致

@yihui
Copy link
Member

yihui commented Jul 31, 2017

@fyears 总结得非常好,我感到无可挑剔。

有一些我拿不准的, 就是比如说谁谁谁翻译,已经在 meta_extra 里标注了,还需要在开头的一大堆说明里再提一次吗?此外开头的一大堆版权、原文链接、原文作者简介用什么包起来?现在好像都是用引用符号包起来,以和真正的原文区别起来。我没有什么建议,因为我也不知道语法上该用啥。

meta_extra 适合显示简单的信息,如本文的编辑是是谁,审校是谁,等等。如果要显示大段的编辑说明(本文写作背景、原始链接,等等),那就用第一个自然段,是否使用引用格式 > 我都没有意见。

现在的行内代码到底是怎么一个格式?要不要反撇号包住金钱号?

如果是纯 Markdown 文章,数学公式格式需要反引号 `$ $`;如果是 R Markdown 文档,则不需要。

我发现大家都在”滥用“引用符号,比如说编者按到底要不要用引用号?

我也有同感。好多引用格式都是没有必要的。关于编者按
是否用引用格式,我没有强烈意见,只是略微倾向于不用。若无必要,不要用特殊格式惊扰读者。

中英文之间空格,英文字母和中文标点之间不用空格。这一点,是我的个人执念。实际执行起来,我认为只要一篇文章内统一就好了。。。

空格问题作者爱咋地咋地,反正我已经加载了盘古:#589


@Lchiffon 理论上这两个限制条件对 blogdown 和 Hugo 来说是不必要的,但对于你的 Chrome 插件有必要,否则就无法从文件名精确预测文章的未来网址了。

“文件名中的date 需要与YAML的date 一致”

“文件名中的 slug需要与YAML的slug一致”

@XueningZhu
Copy link
Contributor Author

@fyears @yihui 感觉你们说的这个可以放在编辑须知里面,就是系列文章,如何编辑等
@Lchiffon 审稿和投稿的得分别放到不同内容下面 你们的审稿指南 有木有动笔呀

@fyears
Copy link
Member

fyears commented Sep 6, 2017

这个要不要关闭了吧?

还是说,还有没有清理好的。。。

@yihui
Copy link
Member

yihui commented Sep 6, 2017

差不多吧,肯定是没有百分百完成,但为了减轻心理压力,就先关了吧。

@yihui yihui closed this as completed Sep 6, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants