Open zepinglee opened 11 months ago
非常全面的建议,我打算以后添加到Wiki中作为我们编写翻译器的规范的一部分。目前借用官方的仓库配置文件可以实现代码的技术性审查,只是现在我们有太多翻译器不合规范了,所以暂时没有启用。等我把这些翻译器都更新一遍之后,我会研究怎么把你提到的这些要求添加到代码审查规则中(关键在.ci/eslint-plugin-zotero-translator/
这个自定义模块上,我们应该也能模仿做出类似的模块),这样我们就可以保证在pull request
的时候就能检查出大部分问题。
我还有个问题想请教,有些网页(一般是书籍条目)的外文作者显示为
(国籍)名・姓(西文名)
应该保留全部吗?我此前采取的做法是仅保留中文名,不知道这样是否可取。
我还有个问题想请教,有些网页(一般是书籍条目)的外文作者显示为
(国籍)名・姓(西文名)
应该保留全部吗?我此前采取的做法是仅保留中文名,不知道这样是否可取。
这点我还没考虑好。有的体例要求专著类文献标注作者国籍,例如《法学引注手册》。目前豆瓣的 translator 抓取为“[国籍]名·姓”,例如“[美]理查德·J. 皮尔斯”。这样的缺点有:
另外 @EdwardSaidZhou 在 EdwardSaidZhou/CSL-Chinese-IR-CSSCI-Journals 提出将 extra
的 Original Publisher Place
用作国籍,这样可以避免前面的问题,但是这个方案只能表示一位作者的国籍,而且跟 “Original Publisher Place”用作“出版地的英文翻译”的方式冲突。
这是元数据的格式化问题,我觉得我们可以求助@northword 的 zotero-format-metadata 项目,商量一下在extra
里约定一个字段保存作者元数据(国籍,firstName,lastName,creatorType)作为备用,必要时用插件可以替换为相应的格式(国籍选用何种括号应当由插件提供必要的选项并由用户根据需要选择)。
感谢这个总结!对插件规范字段数据也很有用!
这是元数据的格式化问题,我觉得我们可以求助 northword 的 zotero-format-metadata 项目
如果作者字段没有其他更多的符号干扰,通过插件替换国籍的括号是可以实现的。
商量一下在extra里约定一个字段保存作者元数据(国籍,firstName,lastName,creatorType)作为备用
存储这些数据可能仍是 translator 是部分,我的插件目前仅处理了已有数据的格式,并且主要针对的都是标准字段,并没有涉及如何和从哪里获取和存储国籍
关于国籍的存储问题, CSL 和 Zotero 都没有任何建议的方案吗?
@northword CSL的情况我不知道,Zotero情况是:creator对象中并没有定义“国籍”这个属性,这给一些需要显示国籍的引用样式带来困难。虽然大部分数据库都没有提供国籍,而且我们也没有必要专门去检索或者猜测creator的国籍,但在数据库给出国籍的情况下,我们应当可以为此做一些努力。
extra
字段只能存储字符串,但一般使用换行和键值对来对数据进行结构化表示,比如
Type: treaty\ndatabseID: XXXX\n
假如我们的翻译器察觉到数据库提供了带有国籍的姓名(这很容易办到,比如用正则^[([〔[【].*?[)\]〕]】]
来匹配那个被括号框住的国籍),我们可以对原有的creator对象做一点拓展,在extra
中记录为
creatorExt: {country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型}
creatorExt: {country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型}
...
正如前面所说,extra
是一个长字符串,所以重复的键是允许的,然后你应该可以用插件读取extra
的值extraVal
并进行进一步处理:
let creators = extraVal.split('\n').filter(keyVal => keyVal.startsWith('creatorExt:'));
creators = creators.map(keyVal => JSON.parse(keyVal.match(/:(.*)/)[1]));
这样我们就获得了结构化的creator,无论用户需要将creator转化为英文名还是在姓前面显示国籍,都比较容易办到了。
@northword 当然,我们也不可能假定用户都使用Zotero Linter,但尽量把原始信息记录下来总是好的。在“记录”的前提下,我们再商量一个便于你插件那边使用的记录格式,就能带来更好的用户体验。
关于国籍的存储问题, CSL 和 Zotero 都没有任何建议的方案吗?
没有。我记得 forum.zotero.org 讨论过,但是国外的参考文献样式一般不会输出作者国籍,所以开发者不太愿意考虑这个功能。
也就是如果要在参考文献样式里输出国籍,就只能通过在作者字段上直接编码国籍,不能从 extra 里读取;
需要插件做的事情是:从 extra 里读取 translator 存储的作者扩展信息(包含国籍、中英文和类型),根据用户选择将国籍加/删到作者字段,以及交换中英文之类的?
这是可以实现的,不过如果是存储为 @jiaojiaodubai 举例的数据(下)的话,我觉得可以把他们按顺序存成一个对象列表 [{作者1}, {作者2}]
,这样插件读取和写入会更方便。
creatorExt: {country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型}
creatorExt: {country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型}
...
creatorExt: [{country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型},
{country:国籍,lastName:英文姓, firstName:英文名,zhName:中文姓名,creatorType:主要责任人类型}, ...]
也就是如果要在参考文献样式里输出国籍,就只能通过在作者字段上直接编码国籍,不能从 extra 里读取;
需要插件做的事情是:从 extra 里读取 translator 存储的作者扩展信息(包含国籍、中英文和类型),根据用户选择将国籍加/删到作者字段,以及交换中英文之类的?
这是可以实现的,不过如果是存储为 @jiaojiaodubai 举例的结构化数据的话,我觉得可以把他们按顺序存成一个对象列表
[{作者1}, {作者2}]
,这样插件读取和写入会更方便。
CSL 也可以从 extra
读取。 还有一种方案是 https://github.com/l0o0/translators_CN/issues/257#issuecomment-1857141667 提到的第二种,即在 extra
中用另外的字段表示国籍,比如 original-publisher-place
或者 nationality
。缺点是只能填一个作者的国籍。考虑到需要填写国籍的主要是人文社科类期刊,很多情况下只有一个作者。但我不太熟这些领域,需要 @EdwardSaidZhou 评估一下会有多大程度的影响。
需要做的是增/删国籍,以及修改国籍的前后缀(因为不同期刊要求的符号不一样)。交换中英文应该不需要,因为需要填写国籍的一般是译本,语言是中文。
@northword 对,按现在的情况来看,要在引用格式中显示国籍只能是直接把带括号的国籍塞到标准字段的姓那里。当用户需要显示国籍的时候,我们要做的不是分别从extra里面读取国籍、从条目已有字段读取姓名然后根据名字和国籍的映射关系拼接;既然作者名和国籍的映射关系是翻译器抓取的时候就已经确定的,我们要做的就是在extra.creatorExt
里读取数据,如果country
值可用,我们直接用extra.creatorExt
里的数据重建creator列表然后替换条目原来的creator列表。
当然,大多数时候的情况是,我们未能获取到creator的国籍,但用户确实想为作者添加国籍,这种情况下你的插件或许可以根据条目现有的creators字段在extra
创建一个creatorExt模板,用户在extra填写完country之后,它就可以自如地使用你的插件从有无国籍和使用何种括号之间自如转换。
需要做的是增/删国籍,以及修改国籍的前后缀(因为不同期刊要求的符号不一样)。交换中英文应该不需要,因为需要填写国籍的一般是译本,语言是中文。
我了解,我在creatoExt添加中英文名字是出于其他方面的考虑。
同一个条目在中英文期刊上引用时,字段就要采取它的中文形式或英文形式。对于标题、出版商、期刊名称这些简单的字段来说,你前面提到的original-*
已经堪用,直接替换就行,但一个creator不仅仅是一个名字,它还有它关联的位置(第一第二作者应该是不能乱的)、关联的creatorType
,但original-author
似乎不能反映creator的这些属性。所以在creatorExt里把中英文名字对应起来的话,在插件里实现条目中英文形式的转换就会比较快。
这个思路就相当于官方没给creator做国籍属性和双语支持,我们就自己在extra做,需要用什么形式我们就(使用插件或手动)从中抽取数据放到标准字段里。
歪个楼,请教书籍的引用,部分样式需要提供 书籍的引用位置的页码 ,这种写在 # of pages
似乎是不对的,我注意到 gbt****csl 仓库是放 extra: page:xxx
的,这种是正确做法嘛?
如果是的话,
按照我的理解,参考文献表最后应该写书籍的总页数的,但总有奇葩出版社要求最后是引注所在处的页码
说一下我知道的情况,https://zhuanlan.zhihu.com/p/429125051 @northword
说一下我知道的情况,https://zhuanlan.zhihu.com/p/429125051 @northword
这个就是我说的 extra: pages:xxx
这种,这明显会存在一个问题,不同的文章中引用同一个书籍,可能页码需要不一致(因为要显示的页码不是总页码,而是引用内容所在的页码)
歪个楼,请教书籍的引用,部分样式需要提供 书籍的引用位置的页码 ,这种写在
# of pages
似乎是不对的,我注意到 gbt****csl 仓库是放extra: page:xxx
的,这种是正确做法嘛?
是的。
- 如果多处引用应该怎么写
参考文献表(bibliography)中不填页码,而在引注(citation)中标注页码。不过国标的 citation 页码位置非常奇葩,跟 CSL 的功能冲突,所以具体的 CSL 样式并不支持。
- 如何做到在不同文档里标记不同来源
理想的情况就是上面所说的“参考文献表(bibliography)中不填页码,而在引注(citation)中标注页码”。像 APA 是这样的,参考文献表中没有具体页码的位置,只能在引注处填写。
- 是否能读取在 插入引注时候的选择pages的那个里面的数值
CSL 目前的设计不能。引注的那个页码在 CSL 中是 locator
变量,与之伴随的有 label
变量,可选的值包括 page
, volume
, figure
等。这个 locator
跟文献 metadata 中的 page
是完全独立的。CSL spec 是这么描述 locator
的:
locator A cite-specific pinpointer within the item (e.g. a page number within a book, or a volume in a multi-volume work); Must be accompanied in the input data by a label indicating the locator type (see the Locators term list), which determines which term is rendered by cs:label when the locator variable is selected.
由于 locator
是“cite-specific”,所以在输出 <bibliography>
的内容时 locator
的值总是空的。
按照我的理解,参考文献表最后应该写书籍的总页数的,但总有奇葩出版社要求最后是引注所在处的页码
其实输出“总页数”的体例不是很多。另外要求“Pages”也不算很奇葩,像 IEEE 就有这样的例子(下图)。其思路应该跟 APA 不太一样,我也不能完全理解。
这种写在
# of pages
似乎是不对的
像 Google books 的 translator 真的会将“总页数”抓取到这个字段,所以如果将其借用表示具体页码 Pages
会有冲突。
我一般反对在字段中填写与其定义不符的内容,例如早些年在 archiveLocation
填写引用数,或者在 series
填写是否某某索引。因为这样混用字段会造成混乱,尤其是不同插件对这些字段的用法还不一致。前文提到的在 original-author
填写英文翻译的方案,严格来说也不符合字段的定义,但 CSL 中能按照姓名格式处理的变量是有限的,这么设计实在是迫不得已。
补充一些 CSL/Zotero 作者的评论:
https://forums.zotero.org/discussion/comment/288866/#Comment_288866
Technically you can export pages to books in Zotero by using
page: 123-145
in the Extra field, but none of our citation styles (and thus pandoc's) are designed to include them for books so either they won't appear or they'll look off.
https://forums.zotero.org/discussion/comment/267110#Comment_267112
individual pages aren't typically cited for books
补充一点,外籍作者的中文译名需要将姓名填写在一起(fieldMode: 1
),如“理查德·J. 皮尔斯”。这是因为 CSL 无法将其与中文姓名区分开。如果分开姓和名会按照姓前名后的顺序输出为“皮尔斯理查德·J.”。我国部分少数民族姓名也按照此格式,如“迪丽热巴·迪力木拉提”。
另外注意间隔号应使用“·”(U+00B7);外文用首字母缩写的点号后有空格。
按照前面的要求,这个页面岂不是没有author了,我企图在翻译器中支持这个页面,不过要是它缺数据的话,我就不支持这种条目类型了。
按照前面的要求,这个页面岂不是没有author了,我企图在翻译器中支持这个页面,不过要是它缺数据的话,我就不支持这种条目类型了。
没错,这个页面的字段都不适合作为 author。不过标准文献缺 author 影响不大,有的体例甚至不标注作者。
https://github.com/northword/zotero-format-metadata/issues/110 补充:期刊题名的缩写应保留句点,CSL 可以样式需求选择是否去掉缩写点。
有些standard的“归口单位”会在最后备注一个英文缩写,如:全国信息与文献标准化技术委员会(SAC/TC 4),是否需要去掉后面括号那部分?
有些standard的“归口单位”会在最后备注一个英文缩写,如:全国信息与文献标准化技术委员会(SAC/TC 4),是否需要去掉后面括号那部分?
这个应该影响不大,方便的话就去掉吧。
我看到国标给的例子是把“会议录”当作专著引用,因此需要主办方+出版社+出版地;而Zotero中的ConferencePaper
是指会议文章。当前GB相关的CSL样式将ConferencePaper
看作何种类型来输出?如果是按国标那样的话,很多数据库其实并不提供会议论文的出版社、出版地这样的信息,编写转换器比较困难。
此外我注意到,国内一些standard的标题中含有一个全角空格,如信息与文献 参考文献著录规则
,但在大多数数据库的导出结果这,这个空格会变成半角空格,从规范的角度看,有没有必要把这个半角空格替换成全角空格?
@zepinglee
我看到国标给的例子是把“会议录”当作专著引用,因此需要主办方+出版社+出版地;而Zotero中的
ConferencePaper
是指会议文章。当前GB相关的CSL样式将ConferencePaper
看作何种类型来输出?
“会议录”属于“专著”,而 ConferencePaper
属于“专著中的析出文献”,见 4.2.2 节示例 [5]。
另外“//”后的是“专著主要责任者”,通常为编者 editor,不是“主办方”。
如果是按国标那样的话,很多数据库其实并不提供会议论文的出版社、出版地这样的信息,
是的,一些会议甚至都不会正式出版论文集,就更没有出版社、出版地了,我觉得置空就可以。
编写转换器比较困难。
有没有具体案例?
此外我注意到,国内一些standard的标题中含有一个全角空格,如
信息与文献 参考文献著录规则
,但在大多数数据库的导出结果这,这个空格会变成半角空格,从规范的角度看,有没有必要把这个半角空格替换成全角空格?
从排版的严谨性上有必要。我甚至看到过用两个西文空格表示全角空格的。注意检查空格前后都是汉字,因为有些可能在中英文字符间加空格,这些不应替换为全角空格。大概是 replace(/([\u4E00-\u9FFF])\s+([\u4E00-\u9FFF])/, '$1 $2')
。
编写转换器比较困难。
有没有具体案例?
我的意思是在缺少那些数据的时候,抓取结果不够完整。既然可以置空的话,我这边就好办了。
@jiaojiaodubai @northword 纠正一下关于“网络首发”时间的错误。严格来说 advance publication online 时间跟正式出版时间不一样,我之前理解为填在 available-date
字段。但是我检查了一些外文 CSL 样式,目前还没有使用这个字段的,包括 APA, MLA, Chicago。所以建议“网络首发时间”同样填在 date
。
我稍后搞个 PR 处理一下 l0o0/translators_CN 中已有的 available-date
。
您好,请问预印本的国标引文样式应该是什么样的,对应preprint哪些字段呢?
您好,请问预印本的国标引文样式应该是什么样的,对应preprint哪些字段呢?
国标没有规定预印本的格式,也没有示例。通常按照 4.6 节电子资源格式处理,文献类型标识使用“A”(档案)。对应的字段参考官方的 arXiv 示例 https://github.com/zotero/translators/blob/1c99c1a2b088cbb31218b9ad9f7aff5ea300537f/arXiv.org.js#L589-L645。
您好,请问预印本的国标引文样式应该是什么样的,对应preprint哪些字段呢?
国标没有规定预印本的格式,也没有示例。通常按照 4.6 节电子资源格式处理,文献类型标识使用“A”(档案)。对应的字段参考官方的 arXiv 示例 https://github.com/zotero/translators/blob/1c99c1a2b088cbb31218b9ad9f7aff5ea300537f/arXiv.org.js#L589-L645。 好的,那我明白了,我自己自定义一下csl,非常感谢!
creators: 外籍作者的中文译名需要将姓名填写在一起(fieldMode: 1),如“理查德·J. 皮尔斯”。这是因为 CSL 无法将其与中国姓名区分开。如果分开姓和名会按照姓前名后的顺序输出为“皮尔斯理查德·J.”。我国部分少数民族姓名也按照此格式,如“迪丽热巴·迪力木拉提”。另外注意间隔号应使用“·”(U+00B7);外文用首字母缩写的点号后有空格。
中国作者的中文名是否也需要填在一起呢?
@jiaojiaodubai : 大多数情况下,中文名字的姓和名需要一并输出,所以zeping说中文姓名最好是只放在lastName,然后fieldMode为1,当作一个机构名称来看待(虽然官方那边的文档不推荐混淆人名和机构名)。 但是,有一种案例,就是author-date格式的CSL style,如果中文名没拆分的话,逗号显示会异常。 这一点在我们之前做的style分发站点也写了
@jiaojiaodubai 截图里的页面是过时的页面,在新的页面上线前,不应把它作为参考。
中文姓名一并输出似乎是可以通过 CSL 控制?
所以对于中国作者的中文名应该按照姓和名分开存储?
之前的讨论:Pull#144
中国作者的中文名是否也需要填在一起呢?
都可以,对 CSL 的输出不影响。你们定一个统一的标准就行。
但是,有一种案例,就是author-date格式的CSL style,如果中文名没拆分的话,逗号显示会异常。
我印象中这是早期某些 CSL 样式没有正确设置的原因(记得在某 issue 中回复过,但是一时找不到了)。目前 https://github.com/redleafnew/Chinese-STD-GB-T-7714-related-csl 的样式中没这个问题。
截图里的页面是过时的页面,在新的页面上线前,不应把它作为参考。
应该是过时了。
中文姓名一并输出似乎是可以通过 CSL 控制?
是的,只要开启 CSL-M 的扩展功能就可以针对中文姓名格式进行控制。
所以对于中国作者的中文名应该按照姓和名分开存储?
同上。
录音、电影等条目的时长、艺术品的尺寸应该取什么单位(或格式)?Zotero 的 Fields 文档里没有提及,是否有引注标准对此有规定?@zepinglee
录音、电影等条目的时长、艺术品的尺寸应该取什么单位(或格式)?Zotero 的 Fields 文档里没有提及,是否有引注标准对此有规定?@zepinglee
从 Chicago 的示例来看,电影时长多用 [HH:]MM:SS
的格式。
艺术品的尺寸应该用任何单位都可以,比如下面的 9½ × 13″ (24.1 × 33 cm)
, 39.3 × 37 cm
。
关于法律法规“颁布日期”的详细讨论见 #345
@zepinglee 类似 Genre
这样的单词(非复合词)写为全小写 genre
似乎也能正常读取,关于 extra
里的键名大小写,有什么推荐的写法吗?
@zepinglee 类似
Genre
这样的单词(非复合词)写为全小写genre
似乎也能正常读取,关于extra
里的键名大小写,有什么推荐的写法吗?
似乎没有统一的写法。
Zotero 导出 CSL 的时候会将首字母大写的字段转为 CSL 的变量,例如 Original Date => original-date
,但似乎仅限 Zotero 识别的字段或者 CSL 变黄的名称。像某些中英文双语的样式中,需要用的 original-container-title 就只能写成 CSL 变量的形式。
我总结了一下中文 CSL 的需求,供 translator 方面参考。理想的情况是,用户从抓取文献到输出引用和参考文献表的过程中无需额外进行编辑。
相关资料:
通用字段
archiveLocation
: 这个字段是档案文献的卷宗号,例如“MC 644, folder 45, box 3”或“北洋档案 1011—5961”。大部分情况下不填。creators
: 外籍作者的中文译名需要将姓名填写在一起(fieldMode: 1
),如“理查德·J. 皮尔斯”。这是因为 CSL 无法将其与中国姓名区分开。如果分开姓和名会按照姓前名后的顺序输出为“皮尔斯理查德·J.”。我国部分少数民族姓名也按照此格式,如“迪丽热巴·迪力木拉提”。另外注意间隔号应使用“·”(U+00B7);外文用首字母缩写的点号后有空格。callNumber
: 这个字段用于档案文献。大部分情况下不填。注意不是期刊的 CN 号。language
: Zotero 建议 storing these as two letter ISO language codes followed by two letter ISO country codes (e.g., en-US for American English, or de-DE for German)。中文通常填写“zh-CN”。如果数据库中既有中文简体又有繁体文献且无法区分(例如豆瓣),建议填写“zh”。注意不应填写“CN”、“chi”、“中文;”、“eng”。libraryCatalog
: 文献的来源,一般填数据库的名称。如果没有设置 Zotero 会自动填写为 translator 的名称。注意不是分类号。pages
: 页码中不要使用“~”或“+”号,如“43-73+92”应改成“43-73, 92”。shortTitle
: 若文献有主标题和副标题,在title
中填写“主标题:副标题”,在shortTitle
中仅填写主标题,如title
:Language learning as language use: A cross-linguistic model of child language development
,shortTitle
:Language learning as language use
。extra
的original-author
,original-title
,original-container-title
,original-publisher-place
,original-publisher
中。这样方便输出中英文双语的参考文献(例如《心理学报》)。book
edition
: 需要填写为阿拉伯数字或者完整的名称,例如“3”、“修订版”、“影印本”,不要填写“3rd”、“III”、“修订”、“影印”。volume
: 同edition
,填写阿拉伯数字或者完整的名称,如“7”、“上册”。conferencePaper
Event Date
应按 ISO 格式填写在extra
中:extra
:Event Date: 2001-12-15/2001-12-31
。有的会议没有正式出版论文,可以将举办日期作为date
。place
: Zotero 不区分会议举办地和出版地,如果期数据库只提供其中一种可填在place
字段。如果两者都提供,应将place
留空,在extra
填写Event Place: Foo\n Publisher Place: Bar
。journalArticle
journalAbbreviation
: 期刊题名的缩写应保留句点,CSL 可以样式需求选择是否去掉缩写点。extra
填写Status: 印刷中
(或者in press
)。date
。并在extra
填写Status: advance online publication
。(我个人认为available-date
更合适,但目前几乎没有样式使用这个字段。)extra
填写Number: xxxx
。issue
期刊的期号需要去掉前面的 0,例如不要填写02
。newspaperArticle
pages
: 报纸文献的版次填写在pages
字段。patent
place
: 专利国别本应填写在country
字段,但是目前 Zotero 导出 CSL-JSON 时没有对应的字段,所以需要在place
也填写专利国别。extra
中填写Genre: 发明专利
。preprint
preprint
类型,不要使用journalArticle
。standard
author
应填写“归口单位”。number
标准号的连接号应使用一字线“—”(U+2014 em dash)。publisher
一般填写出版社(如“中国标准出版社”),不填发布部门。publisher-place
对应出版社的地址,不是“国别”。thesis
thesisType
: 学位论文的类型应填写完整名称,如“硕士学位论文”、“PhD. dissertation”。不要只填写“硕士”或“博士”。Zotero 要求“the word 'thesis' or 'dissertation' should be included where applicable”。法律文献
case
,statute
statute
类型,但需要分别在extra
填写“Type: regulation”和“Type: treaty”。