diff --git a/.gitignore b/.gitignore index c34e1efdab5..2fcb4622a3d 100644 --- a/.gitignore +++ b/.gitignore @@ -8,4 +8,10 @@ book/website/Pipfile book/website/Pipfile\.lock -workshops/boost-research-reproducibility-binder/workshop-presentations/*pptx \ No newline at end of file +workshops/boost-research-reproducibility-binder/workshop-presentations/*pptx + +_config-locale.yml + +po4jupyterbook/ + +*.po~ \ No newline at end of file diff --git a/book/.gitignore b/book/.gitignore index 91e22541b2e..d46269ea793 100644 --- a/book/.gitignore +++ b/book/.gitignore @@ -56,7 +56,10 @@ coverage.xml # Translations *.mo -*.pot +# *.pot +POTFILES.in +locale/ +toc.yml.bak # Django stuff: *.log diff --git a/book/content/po/Ethical_Decisions.es.po b/book/content/po/Ethical_Decisions.es.po new file mode 100644 index 00000000000..ac5704142ed --- /dev/null +++ b/book/content/po/Ethical_Decisions.es.po @@ -0,0 +1,197 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:6 +# header +msgid "## Summary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:15 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:35 +# header +msgid "## Checklist" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:36 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:39 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:41 +# header +msgid "## Further reading" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:42 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:43 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:45 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:46 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:48 +# header +msgid "## Bibliography" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:49 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + diff --git a/book/content/po/Ethical_Decisions.pot b/book/content/po/Ethical_Decisions.pot new file mode 100644 index 00000000000..c84081b8a09 --- /dev/null +++ b/book/content/po/Ethical_Decisions.pot @@ -0,0 +1,197 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:6 +# header +msgid "## Summary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:15 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:35 +# header +msgid "## Checklist" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:36 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:39 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:41 +# header +msgid "## Further reading" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:42 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:43 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:45 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:46 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:48 +# header +msgid "## Bibliography" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:49 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + diff --git a/book/content/po/Ethical_Decisions.tr.po b/book/content/po/Ethical_Decisions.tr.po new file mode 100644 index 00000000000..c84081b8a09 --- /dev/null +++ b/book/content/po/Ethical_Decisions.tr.po @@ -0,0 +1,197 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:6 +# header +msgid "## Summary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:15 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:35 +# header +msgid "## Checklist" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:36 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:39 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:41 +# header +msgid "## Further reading" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:42 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:43 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:45 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:46 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:48 +# header +msgid "## Bibliography" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:49 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + diff --git a/book/content/po/Ethical_Decisions.zh_CN.po b/book/content/po/Ethical_Decisions.zh_CN.po new file mode 100644 index 00000000000..54cf7840a69 --- /dev/null +++ b/book/content/po/Ethical_Decisions.zh_CN.po @@ -0,0 +1,198 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:6 +# header +msgid "## Summary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:15 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:35 +# header +msgid "## Checklist" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:36 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:39 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:41 +# header +msgid "## Further reading" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:42 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:43 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:45 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:46 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:48 +# header +msgid "## Bibliography" +msgstr "" + +#: Ethical_Decisions/Planning_Research.md:49 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + diff --git a/book/content/po/LINGUAS b/book/content/po/LINGUAS new file mode 100644 index 00000000000..8357fcaaed4 --- /dev/null +++ b/book/content/po/LINGUAS @@ -0,0 +1 @@ +es diff --git a/book/content/po/binderhub.es.po b/book/content/po/binderhub.es.po new file mode 100644 index 00000000000..aea7087846c --- /dev/null +++ b/book/content/po/binderhub.es.po @@ -0,0 +1,543 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: binderhub/binderhub.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: binderhub/binderhub.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: binderhub/binderhub.md:10 +# header +msgid "## Table of Contents" +msgstr "" + +#: binderhub/binderhub.md:12 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: binderhub/binderhub.md:28 +# header +msgid "## Summary" +msgstr "" + +#: binderhub/binderhub.md:30 +msgid "This chapter will discuss [BinderHub](https://binderhub.readthedocs.io/en/latest/index.html), which is the cloud technology powering [Binder](https://mybinder.readthedocs.io/en/latest/)." +msgstr "" + +#: binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: binderhub/binderhub.md:36 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: binderhub/binderhub.md:136 +# header +msgid "## Further reading" +msgstr "" + +#: binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: binderhub/binderhub.md:144 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: binderhub/binderhub.md:158 +# header +msgid "## Bibliography" +msgstr "" + +#: binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + diff --git a/book/content/po/binderhub.pot b/book/content/po/binderhub.pot new file mode 100644 index 00000000000..3c356f19cbe --- /dev/null +++ b/book/content/po/binderhub.pot @@ -0,0 +1,543 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: binderhub/binderhub.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: binderhub/binderhub.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: binderhub/binderhub.md:10 +# header +msgid "## Table of Contents" +msgstr "" + +#: binderhub/binderhub.md:12 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: binderhub/binderhub.md:28 +# header +msgid "## Summary" +msgstr "" + +#: binderhub/binderhub.md:30 +msgid "This chapter will discuss [BinderHub](https://binderhub.readthedocs.io/en/latest/index.html), which is the cloud technology powering [Binder](https://mybinder.readthedocs.io/en/latest/)." +msgstr "" + +#: binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: binderhub/binderhub.md:36 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: binderhub/binderhub.md:136 +# header +msgid "## Further reading" +msgstr "" + +#: binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: binderhub/binderhub.md:144 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: binderhub/binderhub.md:158 +# header +msgid "## Bibliography" +msgstr "" + +#: binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + diff --git a/book/content/po/binderhub.tr.po b/book/content/po/binderhub.tr.po new file mode 100644 index 00000000000..3c356f19cbe --- /dev/null +++ b/book/content/po/binderhub.tr.po @@ -0,0 +1,543 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: binderhub/binderhub.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: binderhub/binderhub.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: binderhub/binderhub.md:10 +# header +msgid "## Table of Contents" +msgstr "" + +#: binderhub/binderhub.md:12 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: binderhub/binderhub.md:28 +# header +msgid "## Summary" +msgstr "" + +#: binderhub/binderhub.md:30 +msgid "This chapter will discuss [BinderHub](https://binderhub.readthedocs.io/en/latest/index.html), which is the cloud technology powering [Binder](https://mybinder.readthedocs.io/en/latest/)." +msgstr "" + +#: binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: binderhub/binderhub.md:36 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: binderhub/binderhub.md:136 +# header +msgid "## Further reading" +msgstr "" + +#: binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: binderhub/binderhub.md:144 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: binderhub/binderhub.md:158 +# header +msgid "## Bibliography" +msgstr "" + +#: binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + diff --git a/book/content/po/binderhub.zh_CN.po b/book/content/po/binderhub.zh_CN.po new file mode 100644 index 00000000000..aa2ac3f9c7d --- /dev/null +++ b/book/content/po/binderhub.zh_CN.po @@ -0,0 +1,688 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 15:59:16+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +# header +#: binderhub/binderhub.md:1 +msgid "# BinderHub" +msgstr "" + +# header +#: binderhub/binderhub.md:3 +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: binderhub/binderhub.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: binderhub/binderhub.md:7 +msgid "" +"| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: binderhub/binderhub.md:8 +msgid "" +"| [Reproducible Environments](/reproducible_environments/" +"reproducible_environments) | Very Important | Particularly read the section " +"on [Binder](https://the-turing-way.netlify.com/reproducible_environments/" +"reproducible_environments.html#Binder_section). |" +msgstr "" + +# header +#: binderhub/binderhub.md:10 +msgid "## Table of Contents" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:12 +msgid "- [Summary](#summary)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:13 +msgid "" +"- [How this will help you/ why this is useful](#how-this-will-help-you-why-" +"this-is-useful)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:14 +msgid "" +"- [What is BinderHub and why is it good for Reproducibility?](#what-is-" +"binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:15 +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:16 +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:17 +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:18 +msgid " - [Helm](#helm)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:19 +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:20 +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:21 +msgid "" +" - [What happens when a Binder link is clicked?](#what-happens-when-a-" +"binder-link-is-clicked)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:22 +msgid "" +"- [Why would you build your own BinderHub?](#why-would-you-build-your-own-" +"binderhub)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:23 +msgid "" +" - [Issues you may face when deploying a BinderHub](#issues-you-may-face-" +"when-deploying-a-binderhub)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:24 +msgid "- [Further reading](#further-reading)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:25 +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:26 +msgid "- [Bibliography](#bibliography)" +msgstr "" + +# header +#: binderhub/binderhub.md:28 +msgid "## Summary" +msgstr "" + +#: binderhub/binderhub.md:30 +msgid "" +"This chapter will discuss [BinderHub](https://binderhub.readthedocs.io/en/" +"latest/index.html), which is the cloud technology powering [Binder](https://" +"mybinder.readthedocs.io/en/latest/)." +msgstr "这章将会讨论" + +#: binderhub/binderhub.md:31 +msgid "" +"We will cover the technologies and tools that BinderHub utilises and the " +"resources you will need to setup your own BinderHub." +msgstr "" + +#: binderhub/binderhub.md:33 +msgid "" +"This chapter is primarily aimed at Research Software Engineers and IT " +"Services who wish to provide a BinderHub as a service to a group of " +"researchers." +msgstr "" + +#: binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +# header +#: binderhub/binderhub.md:36 +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: binderhub/binderhub.md:38 +msgid "" +"Reading this chapter will give you a clearer picture of how Binder services " +"(such as [mybinder.org](https://mybinder.org)) operate, the technologies " +"powering BinderHub and how they interact with one another." +msgstr "" + +#: binderhub/binderhub.md:39 +msgid "" +"This chapter also covers reasons why you might build your own BinderHub, " +"rather than using the public service at mybinder.org." +msgstr "" + +# header +#: binderhub/binderhub.md:41 +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: binderhub/binderhub.md:43 +msgid "" +"[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a " +"cloud-based technology that can launch a repository of code (from GitHub, " +"GitLab, and others) in a browser window such that the code can be executed " +"and interacted with." +msgstr "" + +#: binderhub/binderhub.md:44 +msgid "" +"A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: binderhub/binderhub.md:46 +msgid "" +"The purpose of these Binder instances is to promote reproducibility in " +"research projects by encouraging researchers to document their software " +"dependencies and produce fun, interactive environments!" +msgstr "" + +#: binderhub/binderhub.md:48 +msgid "" +"Binder, as a user interface, is useful for reproducibility because the code " +"needs to be version controlled and the computational environment needs to be " +"documented in order to benefit from the functionality of Binder." +msgstr "" + +#: binderhub/binderhub.md:49 +msgid "" +"Each change to the code repository also forces a new build of the Binder " +"instance." +msgstr "" + +#: binderhub/binderhub.md:50 +msgid "" +"This acts as a proxy for continuous integration of the computational " +"environment as the Binder instance will break if the configuration file is " +"not updated." +msgstr "" + +#: binderhub/binderhub.md:52 +msgid "" +"Learn more about Continuous Integration in [this chapter](/" +"continuous_integration/continuous_integration)." +msgstr "" + +# header +#: binderhub/binderhub.md:54 +msgid "## How does a BinderHub work?" +msgstr "" + +#: binderhub/binderhub.md:56 +msgid "" +"BinderHub relies on different tools and resources in order to create and " +"launch the Binder instances." +msgstr "" + +#: binderhub/binderhub.md:58 +msgid "" +"For more information, see this [high-level explanation of the BinderHub " +"architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: binderhub/binderhub.md:60 +msgid "" +"| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/" +"e4125eaf-" +"b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book" +"%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: binderhub/binderhub.md:62 +msgid "" +"| A representation of the BinderHub architecture. This image was created by " +"[Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is " +"used under a CC-BY licence. |" +msgstr "" + +# header +#: binderhub/binderhub.md:64 +msgid "### Compute Resources" +msgstr "" + +#: binderhub/binderhub.md:66 +msgid "" +"BinderHub is cloud-neutral which means it can be deployed on any cloud " +"platform." +msgstr "" + +#: binderhub/binderhub.md:67 +msgid "" +"Therefore, the minimum requirement is a subscription to a cloud platform of " +"your choosing." +msgstr "" + +#: binderhub/binderhub.md:69 +msgid "" +"In fact, BinderHub is not dependent on cloud-hosting at all and can be " +"deployed onto an on-premise computing system." +msgstr "" + +# header +#: binderhub/binderhub.md:71 +msgid "### Kubernetes" +msgstr "" + +#: binderhub/binderhub.md:73 +msgid "" +"[Kubernetes](https://kubernetes.io/) is a system for automating deployment, " +"scaling (making more or fewer copies), and management of containers across a " +"compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: binderhub/binderhub.md:74 +msgid "" +"BinderHub uses Kubernetes to manage the resources requested by the users of " +"the Binder service, and to support the tools that build the environments." +msgstr "" + +# header +#: binderhub/binderhub.md:76 +msgid "### Helm" +msgstr "" + +#: binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: binderhub/binderhub.md:79 +msgid "" +"Packages come in the form of *Charts* which are a set of instructions to " +"deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:80 +msgid "" +"They can make installing and managing Kubernetes applications much easier " +"and specific Charts for projects can be published online." +msgstr "" + +#: binderhub/binderhub.md:81 +msgid "" +"For example, the Helm Chart for BinderHub is available [here](https://" +"jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +# header +#: binderhub/binderhub.md:83 +msgid "### JupyterHub" +msgstr "" + +#: binderhub/binderhub.md:85 +msgid "" +"[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter " +"Notebooks and containers alike." +msgstr "" + +#: binderhub/binderhub.md:86 +msgid "" +"In the context of Binder, the JupyterHub's main role is to connect the " +"user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: binderhub/binderhub.md:87 +msgid "" +"However, the JupyterHub can be further customised to provide greater control " +"over the operation of the BinderHub." +msgstr "" + +# header +#: binderhub/binderhub.md:89 +msgid "### repo2docker" +msgstr "" + +#: binderhub/binderhub.md:91 +msgid "" +"[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is " +"a tool that automatically builds a Docker image from a code repository given " +"a configuration file." +msgstr "" + +#: binderhub/binderhub.md:92 +msgid "" +"This Docker image will contain all of the code, data and resources that are " +"listed in the repository." +msgstr "" + +#: binderhub/binderhub.md:93 +msgid "" +"All the software required to run the code will also be preinstalled from the " +"configuration file." +msgstr "" + +#: binderhub/binderhub.md:95 +msgid "" +"BinderHub can be thought of as thin layer that sits on top of repo2docker " +"and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +# header +#: binderhub/binderhub.md:97 +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +# ordered list +#: binderhub/binderhub.md:99 +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:100 +msgid "" +"2. BinderHub searches for a Docker image relating to the provided reference " +"(for example, git commit hash, branch or tag)." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:101 +msgid "" +"3. **If a Docker image is not found**, BinderHub requests resources from the " +"Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:102 +msgid " - Fetch the repository," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:103 +msgid "" +" - Build a Docker image containing the software requested in the " +"configuration file," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:104 +msgid " - Push that image to the Docker registry." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:105 +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:106 +msgid "" +"5. JupyterHub requests resources from the Kubernetes cluster to serve the " +"Docker image." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:107 +msgid "" +"6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +# ordered list +#: binderhub/binderhub.md:108 +msgid "" +"7. JupyterHub monitors the container for activity and destroys it after a " +"period of inactivity." +msgstr "" + +# header +#: binderhub/binderhub.md:110 +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: binderhub/binderhub.md:112 +msgid "" +"[mybinder.org](https://mybinder.org/) is the free, public BinderHub that " +"hosts almost 100k Binder launches per week." +msgstr "" + +#: binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: binderhub/binderhub.md:115 +msgid "" +"Binder is an open source project maintained by volunteers and as such they " +"ask that users stay within certain computational limitations in order to " +"keep running costs as low as possible whilst still providing a usable " +"service." +msgstr "" + +#: binderhub/binderhub.md:116 +msgid "" +"By hosting your own BinderHub, you can offer your users much more flexible " +"and tailored resources." +msgstr "" + +#: binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:120 +msgid "- authentication," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:121 +msgid "- greater computational resources per user," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:122 +msgid "- bespoke library stacks and packages," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:123 +msgid "- allowing access to private repos," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:124 +msgid "- persistent storage for users," +msgstr "" + +# unordered list +#: binderhub/binderhub.md:125 +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +# header +#: binderhub/binderhub.md:127 +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: binderhub/binderhub.md:129 +msgid "" +"BinderHubs are becoming increasingly popular amongst universities and " +"research institutes." +msgstr "" + +#: binderhub/binderhub.md:130 +msgid "" +"This is because they can facilitate multiple instances of the same set of " +"notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: binderhub/binderhub.md:132 +msgid "" +"If you are deploying a cloud-hosted BinderHub on behalf of your " +"organisation, you may need specific permissions on your organisation's cloud " +"platform subscription." +msgstr "" + +#: binderhub/binderhub.md:133 +msgid "" +"Which permissions you require will vary based on the cloud platform you have " +"access to and your IT Services policies." +msgstr "" + +#: binderhub/binderhub.md:134 +msgid "" +"At minimum, you'll need to be able to assign [Role Based Access Control " +"(RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/" +"overview) to your resources so they can act autonomously in order to manage " +"user traffic." +msgstr "" + +# header +#: binderhub/binderhub.md:136 +msgid "## Further reading" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:138 +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:139 +msgid "" +"- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index." +"html)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:140 +msgid "" +"- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-" +"jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:141 +msgid "" +"- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:142 +msgid "" +"- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-" +"binderhub-workshop)" +msgstr "" + +# header +#: binderhub/binderhub.md:144 +msgid "## Definitions/glossary" +msgstr "" + +#: binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: binderhub/binderhub.md:148 +msgid "" +"| Docker image | A machine-readable set of instructions to create a " +"specified computational environment.|" +msgstr "" + +#: binderhub/binderhub.md:149 +msgid "" +"| Docker container | An active computational environment executed from a " +"Docker image. |" +msgstr "" + +#: binderhub/binderhub.md:150 +msgid "" +"| Docker registry | A storage and distribution system for named Docker " +"images. The registry allows Docker users to pull images locally, as well as " +"push new images to the registry (given adequate access permissions when " +"applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: binderhub/binderhub.md:151 +msgid "" +"| BinderHub | Technology for hosting reproducible computational " +"environments. |" +msgstr "" + +#: binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +# header +#: binderhub/binderhub.md:158 +msgid "## Bibliography" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:160 +msgid "" +"- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes." +"io/)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:161 +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:162 +msgid "" +"- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?" +"badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +# unordered list +#: binderhub/binderhub.md:163 +msgid "" +"- **Microsoft Azure documentation on Role Based Access Control**: [https://" +"docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://" +"docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" diff --git a/book/content/po/collaborating_github.es.po b/book/content/po/collaborating_github.es.po new file mode 100644 index 00000000000..a52c54bb423 --- /dev/null +++ b/book/content/po/collaborating_github.es.po @@ -0,0 +1,343 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:9 +# header +msgid "## Bibliography" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: collaborating_github/collaborating_github.md:4 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: collaborating_github/collaborating_github.md:6 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: collaborating_github/collaborating_github.md:11 +# header +msgid "## Summary" +msgstr "" + +#: collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + diff --git a/book/content/po/collaborating_github.pot b/book/content/po/collaborating_github.pot new file mode 100644 index 00000000000..56f9eca688e --- /dev/null +++ b/book/content/po/collaborating_github.pot @@ -0,0 +1,343 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:9 +# header +msgid "## Bibliography" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: collaborating_github/collaborating_github.md:4 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: collaborating_github/collaborating_github.md:6 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: collaborating_github/collaborating_github.md:11 +# header +msgid "## Summary" +msgstr "" + +#: collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + diff --git a/book/content/po/collaborating_github.tr.po b/book/content/po/collaborating_github.tr.po new file mode 100644 index 00000000000..56f9eca688e --- /dev/null +++ b/book/content/po/collaborating_github.tr.po @@ -0,0 +1,343 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:9 +# header +msgid "## Bibliography" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: collaborating_github/collaborating_github.md:4 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: collaborating_github/collaborating_github.md:6 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: collaborating_github/collaborating_github.md:11 +# header +msgid "## Summary" +msgstr "" + +#: collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + diff --git a/book/content/po/collaborating_github.zh_CN.po b/book/content/po/collaborating_github.zh_CN.po new file mode 100644 index 00000000000..9eca35faae3 --- /dev/null +++ b/book/content/po/collaborating_github.zh_CN.po @@ -0,0 +1,344 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:9 +# header +msgid "## Bibliography" +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: collaborating_github/collaborating_github.md:4 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: collaborating_github/collaborating_github.md:6 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: collaborating_github/collaborating_github.md:11 +# header +msgid "## Summary" +msgstr "" + +#: collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + diff --git a/book/content/po/continuous_integration.es.po b/book/content/po/continuous_integration.es.po new file mode 100644 index 00000000000..ec945a546d3 --- /dev/null +++ b/book/content/po/continuous_integration.es.po @@ -0,0 +1,1259 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: continuous_integration/continuous_integration.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:10 +# header +msgid "## Table of contents" +msgstr "" + +#: continuous_integration/continuous_integration.md:12 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: continuous_integration/continuous_integration.md:43 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:44 +# header +msgid "## Summary" +msgstr "" + +#: continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:49 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:153 +#: continuous_integration/continuous_integration.md:158 +msgid "or" +msgstr "" + +#: continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: continuous_integration/continuous_integration.md:370 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:371 +# header +msgid "## Checklist" +msgstr "" + +#: continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:387 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:388 +# header +msgid "## What to learn next" +msgstr "" + +#: continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: continuous_integration/continuous_integration.md:392 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:393 +# header +msgid "## Further reading" +msgstr "" + +#: continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:401 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:402 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:416 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:417 +# header +msgid "## Bibliography" +msgstr "" + +#: continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + diff --git a/book/content/po/continuous_integration.pot b/book/content/po/continuous_integration.pot new file mode 100644 index 00000000000..cf7ba6c2cbb --- /dev/null +++ b/book/content/po/continuous_integration.pot @@ -0,0 +1,1259 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: continuous_integration/continuous_integration.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:10 +# header +msgid "## Table of contents" +msgstr "" + +#: continuous_integration/continuous_integration.md:12 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: continuous_integration/continuous_integration.md:43 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:44 +# header +msgid "## Summary" +msgstr "" + +#: continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:49 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:153 +#: continuous_integration/continuous_integration.md:158 +msgid "or" +msgstr "" + +#: continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: continuous_integration/continuous_integration.md:370 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:371 +# header +msgid "## Checklist" +msgstr "" + +#: continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:387 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:388 +# header +msgid "## What to learn next" +msgstr "" + +#: continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: continuous_integration/continuous_integration.md:392 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:393 +# header +msgid "## Further reading" +msgstr "" + +#: continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:401 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:402 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:416 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:417 +# header +msgid "## Bibliography" +msgstr "" + +#: continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + diff --git a/book/content/po/continuous_integration.tr.po b/book/content/po/continuous_integration.tr.po new file mode 100644 index 00000000000..cf7ba6c2cbb --- /dev/null +++ b/book/content/po/continuous_integration.tr.po @@ -0,0 +1,1259 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: continuous_integration/continuous_integration.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:10 +# header +msgid "## Table of contents" +msgstr "" + +#: continuous_integration/continuous_integration.md:12 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: continuous_integration/continuous_integration.md:43 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:44 +# header +msgid "## Summary" +msgstr "" + +#: continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:49 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:153 +#: continuous_integration/continuous_integration.md:158 +msgid "or" +msgstr "" + +#: continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: continuous_integration/continuous_integration.md:370 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:371 +# header +msgid "## Checklist" +msgstr "" + +#: continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:387 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:388 +# header +msgid "## What to learn next" +msgstr "" + +#: continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: continuous_integration/continuous_integration.md:392 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:393 +# header +msgid "## Further reading" +msgstr "" + +#: continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:401 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:402 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:416 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:417 +# header +msgid "## Bibliography" +msgstr "" + +#: continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + diff --git a/book/content/po/continuous_integration.zh_CN.po b/book/content/po/continuous_integration.zh_CN.po new file mode 100644 index 00000000000..3acfae2fc31 --- /dev/null +++ b/book/content/po/continuous_integration.zh_CN.po @@ -0,0 +1,1260 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: continuous_integration/continuous_integration.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: continuous_integration/continuous_integration.md:10 +# header +msgid "## Table of contents" +msgstr "" + +#: continuous_integration/continuous_integration.md:12 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: continuous_integration/continuous_integration.md:43 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:44 +# header +msgid "## Summary" +msgstr "" + +#: continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:49 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:153 +#: continuous_integration/continuous_integration.md:158 +msgid "or" +msgstr "" + +#: continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: continuous_integration/continuous_integration.md:370 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:371 +# header +msgid "## Checklist" +msgstr "" + +#: continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: continuous_integration/continuous_integration.md:387 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:388 +# header +msgid "## What to learn next" +msgstr "" + +#: continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: continuous_integration/continuous_integration.md:392 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:393 +# header +msgid "## Further reading" +msgstr "" + +#: continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: continuous_integration/continuous_integration.md:401 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:402 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: continuous_integration/continuous_integration.md:416 +msgid "" +msgstr "" + +#: continuous_integration/continuous_integration.md:417 +# header +msgid "## Bibliography" +msgstr "" + +#: continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + diff --git a/book/content/po/credit.es.po b/book/content/po/credit.es.po new file mode 100644 index 00000000000..ef76cb58905 --- /dev/null +++ b/book/content/po/credit.es.po @@ -0,0 +1,412 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: credit/credit.md:3 +#: credit/credit.md:86 +msgid "" +msgstr "" + +#: credit/credit.md:11 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: credit/credit.md:21 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: credit/credit.md:28 +# header +msgid "## Summary" +msgstr "" + +#: credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: credit/credit.md:32 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: credit/credit.md:48 +msgid "" +msgstr "" + +#: credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: credit/credit.md:59 +msgid "" +msgstr "" + +#: credit/credit.md:60 +msgid "" +msgstr "" + +#: credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: credit/credit.md:70 +msgid "" +msgstr "" + +#: credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: credit/credit.md:82 +msgid "" +msgstr "" + +#: credit/credit.md:84 +msgid "" +msgstr "" + +#: credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: credit/credit.md:105 +# header +msgid "## Checklist" +msgstr "" + +#: credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: credit/credit.md:125 +msgid "" +msgstr "" + +#: credit/credit.md:127 +# header +msgid "## Further reading" +msgstr "" + +#: credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: credit/credit.md:132 +msgid "" +msgstr "" + +#: credit/credit.md:134 +msgid "" +msgstr "" + diff --git a/book/content/po/credit.pot b/book/content/po/credit.pot new file mode 100644 index 00000000000..0599b18528b --- /dev/null +++ b/book/content/po/credit.pot @@ -0,0 +1,412 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: credit/credit.md:3 +#: credit/credit.md:86 +msgid "" +msgstr "" + +#: credit/credit.md:11 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: credit/credit.md:21 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: credit/credit.md:28 +# header +msgid "## Summary" +msgstr "" + +#: credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: credit/credit.md:32 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: credit/credit.md:48 +msgid "" +msgstr "" + +#: credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: credit/credit.md:59 +msgid "" +msgstr "" + +#: credit/credit.md:60 +msgid "" +msgstr "" + +#: credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: credit/credit.md:70 +msgid "" +msgstr "" + +#: credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: credit/credit.md:82 +msgid "" +msgstr "" + +#: credit/credit.md:84 +msgid "" +msgstr "" + +#: credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: credit/credit.md:105 +# header +msgid "## Checklist" +msgstr "" + +#: credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: credit/credit.md:125 +msgid "" +msgstr "" + +#: credit/credit.md:127 +# header +msgid "## Further reading" +msgstr "" + +#: credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: credit/credit.md:132 +msgid "" +msgstr "" + +#: credit/credit.md:134 +msgid "" +msgstr "" + diff --git a/book/content/po/credit.tr.po b/book/content/po/credit.tr.po new file mode 100644 index 00000000000..0599b18528b --- /dev/null +++ b/book/content/po/credit.tr.po @@ -0,0 +1,412 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: credit/credit.md:3 +#: credit/credit.md:86 +msgid "" +msgstr "" + +#: credit/credit.md:11 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: credit/credit.md:21 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: credit/credit.md:28 +# header +msgid "## Summary" +msgstr "" + +#: credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: credit/credit.md:32 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: credit/credit.md:48 +msgid "" +msgstr "" + +#: credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: credit/credit.md:59 +msgid "" +msgstr "" + +#: credit/credit.md:60 +msgid "" +msgstr "" + +#: credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: credit/credit.md:70 +msgid "" +msgstr "" + +#: credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: credit/credit.md:82 +msgid "" +msgstr "" + +#: credit/credit.md:84 +msgid "" +msgstr "" + +#: credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: credit/credit.md:105 +# header +msgid "## Checklist" +msgstr "" + +#: credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: credit/credit.md:125 +msgid "" +msgstr "" + +#: credit/credit.md:127 +# header +msgid "## Further reading" +msgstr "" + +#: credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: credit/credit.md:132 +msgid "" +msgstr "" + +#: credit/credit.md:134 +msgid "" +msgstr "" + diff --git a/book/content/po/credit.zh_CN.po b/book/content/po/credit.zh_CN.po new file mode 100644 index 00000000000..88372feac0e --- /dev/null +++ b/book/content/po/credit.zh_CN.po @@ -0,0 +1,413 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: credit/credit.md:3 +#: credit/credit.md:86 +msgid "" +msgstr "" + +#: credit/credit.md:11 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: credit/credit.md:21 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: credit/credit.md:28 +# header +msgid "## Summary" +msgstr "" + +#: credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: credit/credit.md:32 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: credit/credit.md:48 +msgid "" +msgstr "" + +#: credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: credit/credit.md:59 +msgid "" +msgstr "" + +#: credit/credit.md:60 +msgid "" +msgstr "" + +#: credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: credit/credit.md:70 +msgid "" +msgstr "" + +#: credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: credit/credit.md:82 +msgid "" +msgstr "" + +#: credit/credit.md:84 +msgid "" +msgstr "" + +#: credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: credit/credit.md:105 +# header +msgid "## Checklist" +msgstr "" + +#: credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: credit/credit.md:125 +msgid "" +msgstr "" + +#: credit/credit.md:127 +# header +msgid "## Further reading" +msgstr "" + +#: credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: credit/credit.md:132 +msgid "" +msgstr "" + +#: credit/credit.md:134 +msgid "" +msgstr "" + diff --git a/book/content/po/figures.es.po b/book/content/po/figures.es.po new file mode 100644 index 00000000000..bb8c9dae872 --- /dev/null +++ b/book/content/po/figures.es.po @@ -0,0 +1,166 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + diff --git a/book/content/po/figures.pot b/book/content/po/figures.pot new file mode 100644 index 00000000000..ca6263d33d8 --- /dev/null +++ b/book/content/po/figures.pot @@ -0,0 +1,166 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + diff --git a/book/content/po/figures.tr.po b/book/content/po/figures.tr.po new file mode 100644 index 00000000000..ca6263d33d8 --- /dev/null +++ b/book/content/po/figures.tr.po @@ -0,0 +1,166 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + diff --git a/book/content/po/figures.zh_CN.po b/book/content/po/figures.zh_CN.po new file mode 100644 index 00000000000..14a3f71d325 --- /dev/null +++ b/book/content/po/figures.zh_CN.po @@ -0,0 +1,167 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + diff --git a/book/content/po/glossary.es.po b/book/content/po/glossary.es.po new file mode 100644 index 00000000000..5790f3acce0 --- /dev/null +++ b/book/content/po/glossary.es.po @@ -0,0 +1,103 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + diff --git a/book/content/po/glossary.pot b/book/content/po/glossary.pot new file mode 100644 index 00000000000..2c8c4e683bb --- /dev/null +++ b/book/content/po/glossary.pot @@ -0,0 +1,103 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + diff --git a/book/content/po/glossary.tr.po b/book/content/po/glossary.tr.po new file mode 100644 index 00000000000..2c8c4e683bb --- /dev/null +++ b/book/content/po/glossary.tr.po @@ -0,0 +1,103 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + diff --git a/book/content/po/glossary.zh_CN.po b/book/content/po/glossary.zh_CN.po new file mode 100644 index 00000000000..06d845f9821 --- /dev/null +++ b/book/content/po/glossary.zh_CN.po @@ -0,0 +1,104 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + diff --git a/book/content/po/introduction.es.po b/book/content/po/introduction.es.po new file mode 100644 index 00000000000..99ebb32aa76 --- /dev/null +++ b/book/content/po/introduction.es.po @@ -0,0 +1,240 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + diff --git a/book/content/po/introduction.pot b/book/content/po/introduction.pot new file mode 100644 index 00000000000..6f1e88257e3 --- /dev/null +++ b/book/content/po/introduction.pot @@ -0,0 +1,240 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + diff --git a/book/content/po/introduction.tr.po b/book/content/po/introduction.tr.po new file mode 100644 index 00000000000..6f1e88257e3 --- /dev/null +++ b/book/content/po/introduction.tr.po @@ -0,0 +1,240 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + diff --git a/book/content/po/introduction.zh_CN.po b/book/content/po/introduction.zh_CN.po new file mode 100644 index 00000000000..8055c29e822 --- /dev/null +++ b/book/content/po/introduction.zh_CN.po @@ -0,0 +1,404 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +# Translators: +# Yini He , 2020 +# Tony Yang , 2020 +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: 2020-02-12 14:41+0000\n" +"Last-Translator: Tony Yang , 2020\n" +"Language-Team: Chinese (China) (https://www.transifex.com/theturingway/teams/107194/zh_CN/)\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Language: zh_CN\n" +"Plural-Forms: nplurals=1; plural=0;\n" + +# header +#: introduction/introduction.md:1 +msgid "# Welcome to the Turing Way" +msgstr "# 欢迎来到The Turing Way" + +#: introduction/introduction.md:3 +msgid "" +"_The Turing Way_ is a lightly opinionated guide to reproducible data " +"science." +msgstr "_The Turing Way_ 是一本稍带个人观点的，关于可再现数据科学的指导手册" + +#: introduction/introduction.md:5 +msgid "" +"Our goal is to provide all the information that researchers need at the " +"start of their projects to ensure that they are easy to reproduce at the " +"end." +msgstr "我们的目标是在研究人员开始项目时，就提供他们关于可再现性的所以知识，以确保在项目完成之后，这些研究易于被重现。" + +#: introduction/introduction.md:7 +msgid "" +"This also means making sure PhD students, postdocs, PIs, and funding teams " +"know which parts of the \"responsibility of reproducibility\" they can " +"affect, and what they should do to nudge data science to being more " +"efficient, effective, and understandable." +msgstr "" +"这也意味着我们需要确保博士生、博士后、导师和资助团队知道他们分别可以做到“实现可重复性”的哪些部分，以及他们应该采取哪些行动，来推动数据科学变得更加高效，有效及易于理解。" + +#: introduction/introduction.md:9 +msgid "" +"![Cartoon of multiple people tending a garden - caption \"our " +"community\"](../figures/community.jpg)" +msgstr "![关于我们社区的卡通绘画](../figures/community.jpg)" + +#: introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "这本书由整个社区协作编写，开放合作是我们的主旨。" + +#: introduction/introduction.md:12 +msgid "" +"If you would like to contribute please [get in touch](https://github.com" +"/alan-turing-institute/the-turing-way#get-in-touch) or visit our " +"[contributing guidelines](https://github.com/alan-turing-institute/the-" +"turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" +"如果您想贡献自己的力量，请与我们[联系](https://github.com/alan-turing-institute/the-turing-way" +"#get-in-touch)或访问我们的[贡献须知](https://github.com/alan-turing-institute/the-" +"turing-way/blob/master/CONTRIBUTING.md)以了解如何开始。" + +#: introduction/introduction.md:14 +msgid "" +"We value the participation of every member of our community and want to " +"ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "我们重视社区中每个成员的参与，并希望确保每个贡献者都将拥有愉快而充实的体验。" + +#: introduction/introduction.md:15 +msgid "" +"Accordingly, everyone who participates in the _Turing Way_ project is " +"expected to show respect and courtesy to other community members at all " +"times." +msgstr "因此，每一个参与_The Turing Way_项目的人都应始终展现出对其他成员的尊重和礼貌。" + +#: introduction/introduction.md:16 +msgid "" +"All contributions must abide by our [code of conduct](https://github.com" +"/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" +"所有贡献都必须遵守我们的[行为准则](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/CODE_OF_CONDUCT.md)。" + +# header +#: introduction/introduction.md:18 +msgid "## A little more background" +msgstr "## 一点点背景介绍" + +#: introduction/introduction.md:20 +msgid "" +"Reproducible research is necessary to ensure that scientific work can be " +"trusted." +msgstr "可重复研究的必要性在于确保科学工作的结果是值得信赖的。" + +#: introduction/introduction.md:21 +msgid "" +"Funders and publishers are beginning to require that publications include " +"access to the underlying data and the analysis code." +msgstr "拨款方和出版商已经开始要求出版物应当包括原始数据及代码。" + +#: introduction/introduction.md:22 +msgid "" +"The goal is to ensure that all results can be independently verified and " +"built upon in future work." +msgstr "其目的是为了确保所有结果可以被第三方独立验证，并给未来的研究提供支持。" + +#: introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "但是有时候说起来容易做起来难。" + +#: introduction/introduction.md:24 +msgid "" +"Sharing these research outputs means understanding data management, library " +"sciences, sofware development, and continuous integration techniques: skills" +" that are not widely taught or expected of academic researchers and data " +"scientists." +msgstr "共享这些研究成果意味着理解数据管理、图书馆学、软件开发和持续集合技术，而这些能力却不是学术研究者和数据科学家广泛学习和掌握的技能。" + +#: introduction/introduction.md:26 +msgid "" +"The Turing Way is a handbook to support students, their supervisors, " +"funders, and journal editors in ensuring that reproducible data science is " +"\"too easy not to do\"." +msgstr "The Turing Way是一本手册，旨在支持学生、他们的导师、拨款方和期刊编辑，以确保可重现科学简单到不能不做。" + +#: introduction/introduction.md:27 +msgid "" +"It will include training material on version control, analysis testing, open" +" and transparent communication with future users, and build on Turing " +"Institute case studies and workshops." +msgstr "它将包括有关版本控制、分析测试、与潜在用户的公开透明沟通的培训材料，并会组织以Turing Institute为基础的个案研究和研讨会。" + +#: introduction/introduction.md:28 +msgid "" +"This project is openly developed and any and all questions, comments and " +"recommendations are welcome at our GitHub repository: [https://github.com" +"/alan-turing-institute/the-turing-way](https://github.com/alan-turing-" +"institute/the-turing-way)." +msgstr "" +"这个项目由社区共同开发，有任何问题、建议和推荐都欢迎来我们的GitHub仓库：[https://github.com/alan-turing-" +"institute/the-turing-way](https://github.com/alan-turing-institute/the-" +"turing-way)。" + +# header +#: introduction/introduction.md:30 +msgid "## The book itself" +msgstr "## 这本书本身" + +#: introduction/introduction.md:32 +msgid "" +"The book that you are reading is a [jupyter book](https://github.com/jupyter" +"/jupyter-book/)." +msgstr "您正在阅读的是一本[Jupyter Book](https://github.com/jupyter/jupyter-book/)。" + +#: introduction/introduction.md:33 +msgid "" +"Jupyter books render markdown documents and jupyter notebooks as static html" +" web pages." +msgstr "Jupyter Book可以将Markdown文档和Jupyter Notebook以静态HTML网页呈现。" + +#: introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "它们易于阅读和导航，也易于编辑和扩展！" + +#: introduction/introduction.md:35 +msgid "" +"There are some great example books at " +"[https://jupyterbook.org](https://jupyterbook.org)." +msgstr "[https://jupyterbook.org](https://jupyterbook.org)上有一些很棒的示例书。" + +#: introduction/introduction.md:37 +msgid "" +"Check out our [contributing guidelines](https://github.com/alan-turing-" +"institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us" +" build the most useful book we can!" +msgstr "" +"查看我们的[贡献准则](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/CONTRIBUTING.md)来了解你该如何帮助我们构建我们竭尽所能开发的最有用的书！" + +# header +#: introduction/introduction.md:39 +msgid "## The Turing Way Community" +msgstr "## The Turing Way社区" + +#: introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "The Turing Way是由一支不可思议的团队创造的……还有您！" + +#: introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "![](../figures/TuringWayTeam.jpg)" + +#: introduction/introduction.md:45 +msgid "" +"The lead investigator for this project is [Dr Kirstie " +"Whitaker](https://whitakerlab.github.io/about)." +msgstr "该项目的首席研究员是[Kirstie Whitaker博士](https://whitakerlab.github.io/about)。" + +#: introduction/introduction.md:46 +msgid "" +"She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk)" +" and senior research associate in the [Department of " +"Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of " +"Cambridge." +msgstr "" +"她是[The Alan Turing " +"Institute](http://turing.ac.uk)的研究员，也是剑桥大学[精神病学系](https://www.psychiatry.cam.ac.uk)的高级研究员" +" 。" + +#: introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "我们的核心贡献者按字母顺序排列：" + +# unordered list +#: introduction/introduction.md:50 +msgid "" +"* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" +"* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#rachael-ainsworth)" + +# unordered list +#: introduction/introduction.md:51 +msgid "" +"* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#becky-arnold)" +msgstr "" +"* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#becky-arnold)" + +# unordered list +#: introduction/introduction.md:52 +msgid "" +"* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#louise-bowler)" +msgstr "" +"* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#louise-bowler)" + +# unordered list +#: introduction/introduction.md:53 +msgid "" +"* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#sarah-gibson)" +msgstr "" +"* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#sarah-gibson)" + +# unordered list +#: introduction/introduction.md:54 +msgid "" +"* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#patricia-herterich)" +msgstr "" +"* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#patricia-herterich)" + +# unordered list +#: introduction/introduction.md:55 +msgid "" +"* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#rosie-higman)" +msgstr "" +"* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#rosie-higman)" + +# unordered list +#: introduction/introduction.md:56 +msgid "" +"* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#anna-krystalli)" +msgstr "" +"* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#anna-krystalli)" + +# unordered list +#: introduction/introduction.md:57 +msgid "" +"* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#alexander-morley)" +msgstr "" +"* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#alexander-morley)" + +# unordered list +#: introduction/introduction.md:58 +msgid "" +"* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#martin-oreilly)" +msgstr "" +"* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-" +"way/blob/master/contributors.md#martin-oreilly)" + +#: introduction/introduction.md:60 +msgid "" +"You can see all of our incredible contributors in our " +"[README](https://github.com/alan-turing-institute/the-turing-" +"way#contributors) file, and screengrabbed below." +msgstr "" +"你可以在[README](https://github.com/alan-turing-institute/the-turing-" +"way#contributors)和下面的截屏中看到我们所有的贡献者" + +#: introduction/introduction.md:62 +msgid "" +"![Grid of pictures and names of project contributors](../figures" +"/contributors-twopanel.png)" +msgstr "![项目贡献者的姓名和图片](../figures/contributors-twopanel.png)" + +# header +#: introduction/introduction.md:64 +msgid "## Citing _The Turing Way_" +msgstr "## 引用 _The Turing Way_" + +#: introduction/introduction.md:66 +msgid "" +"You can reference _The Turing Way_ through the project's Zenodo archive " +"using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" +"您可以通过doi: " +"[10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)在项目的Zenodo存档中引用" +" _The Turing Way_。" + +#: introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "引用格式为：" + +# blockquote, which can be cascaded +#: introduction/introduction.md:70 +msgid "" +"> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, " +"Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The " +"Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). " +"Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" +"> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, " +"Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The " +"Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). " +"Zenodo. http://doi.org/10.5281/zenodo.3233986" + +#: introduction/introduction.md:72 +msgid "" +"Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though " +"to get the most recent version - the one above is not automatically " +"generated and therefore may be out of date." +msgstr "" +"请访问DOI链接以获得最新版本-上述版本不会自动更新，因此可能已经过时[DOI " +"link](https://doi.org/10.5281/zenodo.3233853) " + +#: introduction/introduction.md:73 +msgid "" +"DOIs allow us to archive the repository and they are really valuable to " +"ensure that the work is tracked in academic publications." +msgstr "DOI让我们可以对资源库进行存档，它们对于追踪学术出版物中的贡献非常有价值。" + +#: introduction/introduction.md:75 +msgid "" +"You can also share the human-readable URL to a page in the book, for " +"example: [https://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html](https://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html), but be aware that the " +"project is under development and therefore these links may change over time." +msgstr "" +"您还可以分享书中特定页面的URL链接，例如：[https://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html](https://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html)，但请注意，该项目正在开发中，因此这些链接可能会随着时间而改变。" + +#: introduction/introduction.md:76 +msgid "" +"You might want to include a [web archive link](http://web.archive.org) such " +"as: [https://web.archive.org/web/20191030093753/https://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https" +"://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make " +"sure that you don't end up with broken links everywhere!" +msgstr "" +"您也可以提供一个[Web " +"Archive链接](http://web.archive.org)，例如：[https://web.archive.org/web/20191030093753/https" +"://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https" +"://the-turing-" +"way.netlify.com/reproducibility/03/definitions.html)以确保您不会遇到已经消失的链接！" + +#: introduction/introduction.md:78 +msgid "" +"We really appreciate any references that you make to _The Turing Way_ " +"project in your and we hope it is useful." +msgstr "我们非常感谢您在工作中引用The Turing Way，我们更希望它对您有所帮助。" + +#: introduction/introduction.md:79 +msgid "" +"If you have any questions please [get in touch](https://github.com/alan-" +"turing-institute/the-turing-way#get-in-touch)." +msgstr "" +"如果您有任何问题，请[联系我们](https://github.com/alan-turing-institute/the-turing-way" +"#get-in-touch)." diff --git a/book/content/po/locale.es.po b/book/content/po/locale.es.po new file mode 100644 index 00000000000..b34ed98e13c --- /dev/null +++ b/book/content/po/locale.es.po @@ -0,0 +1,18074 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:3 +#: locale/zh_CN/binderhub/binderhub.md:3 +#: locale/zh_CN/credit/credit.md:11 +#: locale/zh_CN/make/make.md:3 +#: locale/zh_CN/open_research/open_research.md:3 +#: locale/zh_CN/rdm/rdm.md:3 +#: locale/zh_CN/reproducibility/reproducibility.md:3 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:3 +#: locale/zh_CN/version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:6 +#: locale/zh_CN/binderhub/binderhub.md:28 +#: locale/zh_CN/collaborating_github/collaborating_github.md:11 +#: locale/zh_CN/continuous_integration/continuous_integration.md:44 +#: locale/zh_CN/credit/credit.md:28 +#: locale/zh_CN/make/make.md:40 +#: locale/zh_CN/open_research/open_research.md:65 +#: locale/zh_CN/rdm/rdm.md:53 +#: locale/zh_CN/reproducibility/reproducibility.md:13 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:77 +#: locale/zh_CN/reviewing/reviewing.md:8 +#: locale/zh_CN/risk_assessment/risk_assessment.md:27 +#: locale/zh_CN/testing/testing.md:53 +#: locale/zh_CN/version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:15 +#: locale/zh_CN/binderhub/binderhub.md:36 +#: locale/zh_CN/continuous_integration/continuous_integration.md:49 +#: locale/zh_CN/credit/credit.md:32 +#: locale/zh_CN/rdm/rdm.md:64 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:107 +#: locale/zh_CN/reviewing/01/how_helpful.md:1 +#: locale/zh_CN/testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:35 +#: locale/zh_CN/continuous_integration/continuous_integration.md:371 +#: locale/zh_CN/credit/credit.md:105 +#: locale/zh_CN/rdm/rdm.md:486 +#: locale/zh_CN/reproducible_environments/07/checklist.md:3 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:4 +#: locale/zh_CN/testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:36 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:38 +#: locale/zh_CN/continuous_integration/continuous_integration.md:388 +#: locale/zh_CN/open_research/07/resources.md:34 +#: locale/zh_CN/rdm/rdm.md:507 +#: locale/zh_CN/reproducible_environments/08/resources.md:3 +#: locale/zh_CN/reviewing/04/checklists_bib.md:38 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:7 +#: locale/zh_CN/testing/testing.md:656 +#: locale/zh_CN/version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:39 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:41 +#: locale/zh_CN/binderhub/binderhub.md:136 +#: locale/zh_CN/continuous_integration/continuous_integration.md:393 +#: locale/zh_CN/credit/credit.md:127 +#: locale/zh_CN/open_research/07/resources.md:38 +#: locale/zh_CN/rdm/rdm.md:512 +#: locale/zh_CN/reproducible_environments/08/resources.md:9 +#: locale/zh_CN/reviewing/04/checklists_bib.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:10 +#: locale/zh_CN/testing/testing.md:661 +#: locale/zh_CN/version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:42 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:45 +#: locale/zh_CN/binderhub/binderhub.md:144 +#: locale/zh_CN/continuous_integration/continuous_integration.md:402 +#: locale/zh_CN/open_research/07/resources.md:46 +#: locale/zh_CN/rdm/rdm.md:519 +#: locale/zh_CN/reproducible_environments/08/resources.md:15 +#: locale/zh_CN/reviewing/04/checklists_bib.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:14 +#: locale/zh_CN/testing/testing.md:666 +#: locale/zh_CN/version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:48 +#: locale/zh_CN/binderhub/binderhub.md:158 +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:9 +#: locale/zh_CN/continuous_integration/continuous_integration.md:417 +#: locale/zh_CN/open_research/07/resources.md:67 +#: locale/zh_CN/rdm/rdm.md:529 +#: locale/zh_CN/reproducibility/04/resources.md:10 +#: locale/zh_CN/reproducible_environments/08/resources.md:37 +#: locale/zh_CN/reviewing/04/checklists_bib.md:54 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:17 +#: locale/zh_CN/testing/testing.md:701 +#: locale/zh_CN/version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:49 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:5 +#: locale/zh_CN/continuous_integration/continuous_integration.md:3 +#: locale/zh_CN/make/make.md:5 +#: locale/zh_CN/open_research/open_research.md:5 +#: locale/zh_CN/reviewing/reviewing.md:3 +#: locale/zh_CN/version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:10 +#: locale/zh_CN/rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:12 +#: locale/zh_CN/make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:30 +msgid "这章将会讨论" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:6 +#: locale/zh_CN/testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:4 +#: locale/zh_CN/reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:10 +#: locale/zh_CN/make/make.md:12 +#: locale/zh_CN/open_research/open_research.md:11 +#: locale/zh_CN/reproducibility/reproducibility.md:6 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:15 +#: locale/zh_CN/testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:12 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:43 +#: locale/zh_CN/rdm/rdm.md:51 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:75 +#: locale/zh_CN/reviewing/reviewing.md:7 +#: locale/zh_CN/testing/testing.md:52 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:153 +#: locale/zh_CN/continuous_integration/continuous_integration.md:158 +#: locale/zh_CN/version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:370 +#: locale/zh_CN/rdm/rdm.md:484 +#: locale/zh_CN/reproducible_environments/07/checklist.md:1 +#: locale/zh_CN/testing/testing.md:627 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:387 +#: locale/zh_CN/reproducible_environments/08/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:37 +#: locale/zh_CN/testing/testing.md:655 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:392 +#: locale/zh_CN/reproducible_environments/08/resources.md:7 +#: locale/zh_CN/reviewing/04/checklists_bib.md:42 +#: locale/zh_CN/testing/testing.md:660 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:401 +#: locale/zh_CN/reproducible_environments/08/resources.md:13 +#: locale/zh_CN/reviewing/04/checklists_bib.md:45 +#: locale/zh_CN/testing/testing.md:665 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:416 +#: locale/zh_CN/rdm/rdm.md:527 +#: locale/zh_CN/reproducible_environments/08/resources.md:35 +#: locale/zh_CN/reviewing/04/checklists_bib.md:53 +#: locale/zh_CN/testing/testing.md:700 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + +#: locale/zh_CN/credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:3 +#: locale/zh_CN/credit/credit.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:21 +#: locale/zh_CN/open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: locale/zh_CN/credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: locale/zh_CN/credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: locale/zh_CN/credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: locale/zh_CN/credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: locale/zh_CN/credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: locale/zh_CN/credit/credit.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: locale/zh_CN/credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: locale/zh_CN/credit/credit.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:60 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: locale/zh_CN/credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: locale/zh_CN/credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: locale/zh_CN/credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: locale/zh_CN/credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: locale/zh_CN/credit/credit.md:70 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: locale/zh_CN/credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:82 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:84 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: locale/zh_CN/credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: locale/zh_CN/credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: locale/zh_CN/credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: locale/zh_CN/credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: locale/zh_CN/credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: locale/zh_CN/credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: locale/zh_CN/credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: locale/zh_CN/credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: locale/zh_CN/credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: locale/zh_CN/credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: locale/zh_CN/credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: locale/zh_CN/credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: locale/zh_CN/credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: locale/zh_CN/credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: locale/zh_CN/credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: locale/zh_CN/credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:125 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:132 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:134 +msgid "" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + +#: locale/zh_CN/make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: locale/zh_CN/make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: locale/zh_CN/make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: locale/zh_CN/make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: locale/zh_CN/make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: locale/zh_CN/make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: locale/zh_CN/make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: locale/zh_CN/make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: locale/zh_CN/make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: locale/zh_CN/make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: locale/zh_CN/make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: locale/zh_CN/make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: locale/zh_CN/make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: locale/zh_CN/make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: locale/zh_CN/make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: locale/zh_CN/make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: locale/zh_CN/make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: locale/zh_CN/make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: locale/zh_CN/make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: locale/zh_CN/make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: locale/zh_CN/make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: locale/zh_CN/make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: locale/zh_CN/make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: locale/zh_CN/make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: locale/zh_CN/make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: locale/zh_CN/make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: locale/zh_CN/make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:54 +msgid "A " +msgstr "" + +#: locale/zh_CN/make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: locale/zh_CN/make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: locale/zh_CN/make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: locale/zh_CN/make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: locale/zh_CN/make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: locale/zh_CN/make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: locale/zh_CN/make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: locale/zh_CN/make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: locale/zh_CN/make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: locale/zh_CN/make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: locale/zh_CN/make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: locale/zh_CN/make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: locale/zh_CN/make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: locale/zh_CN/make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: locale/zh_CN/make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: locale/zh_CN/make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: locale/zh_CN/make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: locale/zh_CN/make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: locale/zh_CN/make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: locale/zh_CN/make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: locale/zh_CN/make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: locale/zh_CN/make/make.md:86 +msgid " control." +msgstr "" + +#: locale/zh_CN/make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: locale/zh_CN/make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: locale/zh_CN/make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: locale/zh_CN/make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: locale/zh_CN/make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: locale/zh_CN/make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: locale/zh_CN/make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: locale/zh_CN/make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: locale/zh_CN/make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: locale/zh_CN/make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: locale/zh_CN/make/make.md:100 +#: locale/zh_CN/make/make.md:250 +msgid "follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: locale/zh_CN/make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: locale/zh_CN/make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: locale/zh_CN/make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: locale/zh_CN/make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: locale/zh_CN/make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: locale/zh_CN/make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: locale/zh_CN/make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: locale/zh_CN/make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: locale/zh_CN/make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: locale/zh_CN/make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: locale/zh_CN/make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: locale/zh_CN/make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: locale/zh_CN/make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: locale/zh_CN/make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: locale/zh_CN/make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: locale/zh_CN/make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: locale/zh_CN/make/make.md:145 +msgid "**report**." +msgstr "" + +#: locale/zh_CN/make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: locale/zh_CN/make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: locale/zh_CN/make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: locale/zh_CN/make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: locale/zh_CN/make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: locale/zh_CN/make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: locale/zh_CN/make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: locale/zh_CN/make/make.md:168 +msgid "following contents:" +msgstr "" + +#: locale/zh_CN/make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: locale/zh_CN/make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: locale/zh_CN/make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: locale/zh_CN/make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: locale/zh_CN/make/make.md:192 +msgid "will be built." +msgstr "" + +#: locale/zh_CN/make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: locale/zh_CN/make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: locale/zh_CN/make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: locale/zh_CN/make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: locale/zh_CN/make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: locale/zh_CN/make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: locale/zh_CN/make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: locale/zh_CN/make/make.md:201 +msgid "change." +msgstr "" + +#: locale/zh_CN/make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: locale/zh_CN/make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: locale/zh_CN/make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: locale/zh_CN/make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: locale/zh_CN/make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: locale/zh_CN/make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: locale/zh_CN/make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: locale/zh_CN/make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: locale/zh_CN/make/make.md:213 +msgid "the following:" +msgstr "" + +#: locale/zh_CN/make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: locale/zh_CN/make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: locale/zh_CN/make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: locale/zh_CN/make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: locale/zh_CN/make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: locale/zh_CN/make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: locale/zh_CN/make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:232 +msgid "The " +msgstr "" + +#: locale/zh_CN/make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: locale/zh_CN/make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: locale/zh_CN/make/make.md:235 +msgid "top!" +msgstr "" + +#: locale/zh_CN/make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: locale/zh_CN/make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: locale/zh_CN/make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: locale/zh_CN/make/make.md:244 +msgid " make the report." +msgstr "" + +#: locale/zh_CN/make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: locale/zh_CN/make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: locale/zh_CN/make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: locale/zh_CN/make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: locale/zh_CN/make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: locale/zh_CN/make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: locale/zh_CN/make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: locale/zh_CN/make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: locale/zh_CN/make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: locale/zh_CN/make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: locale/zh_CN/make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: locale/zh_CN/make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: locale/zh_CN/make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: locale/zh_CN/make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: locale/zh_CN/make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: locale/zh_CN/make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: locale/zh_CN/make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: locale/zh_CN/make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: locale/zh_CN/make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: locale/zh_CN/make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: locale/zh_CN/make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: locale/zh_CN/make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: locale/zh_CN/make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: locale/zh_CN/make/make.md:302 +msgid "targets:" +msgstr "" + +#: locale/zh_CN/make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: locale/zh_CN/make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: locale/zh_CN/make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: locale/zh_CN/make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: locale/zh_CN/make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: locale/zh_CN/make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: locale/zh_CN/make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: locale/zh_CN/make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: locale/zh_CN/make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: locale/zh_CN/make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: locale/zh_CN/make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: locale/zh_CN/make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: locale/zh_CN/make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: locale/zh_CN/make/make.md:345 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: locale/zh_CN/make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: locale/zh_CN/make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: locale/zh_CN/make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: locale/zh_CN/make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: locale/zh_CN/make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: locale/zh_CN/make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: locale/zh_CN/make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: locale/zh_CN/make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: locale/zh_CN/make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: locale/zh_CN/make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:382 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: locale/zh_CN/make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: locale/zh_CN/make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: locale/zh_CN/make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: locale/zh_CN/make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: locale/zh_CN/make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: locale/zh_CN/make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: locale/zh_CN/make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: locale/zh_CN/make/make.md:413 +msgid "report!" +msgstr "" + +#: locale/zh_CN/make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: locale/zh_CN/make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: locale/zh_CN/make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: locale/zh_CN/make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: locale/zh_CN/make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: locale/zh_CN/make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: locale/zh_CN/make/make.md:425 +msgid "branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: locale/zh_CN/make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: locale/zh_CN/make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:454 +msgid "figures." +msgstr "" + +#: locale/zh_CN/make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: locale/zh_CN/make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: locale/zh_CN/make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: locale/zh_CN/make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: locale/zh_CN/make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: locale/zh_CN/make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: locale/zh_CN/make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: locale/zh_CN/make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: locale/zh_CN/make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: locale/zh_CN/make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: locale/zh_CN/make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: locale/zh_CN/make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: locale/zh_CN/make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: locale/zh_CN/make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: locale/zh_CN/make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: locale/zh_CN/make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: locale/zh_CN/make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: locale/zh_CN/make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: locale/zh_CN/make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: locale/zh_CN/make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: locale/zh_CN/make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: locale/zh_CN/make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: locale/zh_CN/make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: locale/zh_CN/make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: locale/zh_CN/make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: locale/zh_CN/make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: locale/zh_CN/make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: locale/zh_CN/make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: locale/zh_CN/make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: locale/zh_CN/make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: locale/zh_CN/make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: locale/zh_CN/make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: locale/zh_CN/make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: locale/zh_CN/make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: locale/zh_CN/make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: locale/zh_CN/make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: locale/zh_CN/make/make.md:567 +#: locale/zh_CN/make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: locale/zh_CN/make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: locale/zh_CN/make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: locale/zh_CN/make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: locale/zh_CN/make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: locale/zh_CN/make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: locale/zh_CN/make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: locale/zh_CN/make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: locale/zh_CN/make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: locale/zh_CN/make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: locale/zh_CN/make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: locale/zh_CN/make/make.md:589 +msgid "you could add:" +msgstr "" + +#: locale/zh_CN/make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: locale/zh_CN/make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: locale/zh_CN/make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: locale/zh_CN/make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: locale/zh_CN/make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: locale/zh_CN/make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: locale/zh_CN/make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: locale/zh_CN/make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: locale/zh_CN/make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: locale/zh_CN/make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: locale/zh_CN/make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: locale/zh_CN/make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: locale/zh_CN/make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: locale/zh_CN/make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: locale/zh_CN/make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: locale/zh_CN/make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: locale/zh_CN/make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: locale/zh_CN/make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: locale/zh_CN/make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: locale/zh_CN/make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: locale/zh_CN/make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: locale/zh_CN/make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: locale/zh_CN/make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: locale/zh_CN/make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: locale/zh_CN/make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: locale/zh_CN/make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: locale/zh_CN/make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: locale/zh_CN/make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: locale/zh_CN/make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: locale/zh_CN/make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: locale/zh_CN/make/make.md:645 +msgid "repository: " +msgstr "" + +#: locale/zh_CN/make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: locale/zh_CN/make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: locale/zh_CN/make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: locale/zh_CN/make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: locale/zh_CN/make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: locale/zh_CN/make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: locale/zh_CN/make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: locale/zh_CN/make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: locale/zh_CN/make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: locale/zh_CN/make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: locale/zh_CN/make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: locale/zh_CN/make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: locale/zh_CN/make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: locale/zh_CN/make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: locale/zh_CN/make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: locale/zh_CN/make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: locale/zh_CN/make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: locale/zh_CN/make/make.md:674 +msgid " filenames." +msgstr "" + +#: locale/zh_CN/make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: locale/zh_CN/make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: locale/zh_CN/make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: locale/zh_CN/make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: locale/zh_CN/make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: locale/zh_CN/make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: locale/zh_CN/make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: locale/zh_CN/make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: locale/zh_CN/make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: locale/zh_CN/make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: locale/zh_CN/make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: locale/zh_CN/make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: locale/zh_CN/make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: locale/zh_CN/make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: locale/zh_CN/make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: locale/zh_CN/make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: locale/zh_CN/make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: locale/zh_CN/make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: locale/zh_CN/make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: locale/zh_CN/make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: locale/zh_CN/make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: locale/zh_CN/make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: locale/zh_CN/make/make.md:717 +msgid " complex builds." +msgstr "" + +#: locale/zh_CN/make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: locale/zh_CN/make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: locale/zh_CN/make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: locale/zh_CN/make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: locale/zh_CN/make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: locale/zh_CN/make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: locale/zh_CN/make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: locale/zh_CN/make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: locale/zh_CN/make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: locale/zh_CN/make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: locale/zh_CN/make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: locale/zh_CN/make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: locale/zh_CN/make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: locale/zh_CN/make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: locale/zh_CN/make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: locale/zh_CN/make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: locale/zh_CN/make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: locale/zh_CN/make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: locale/zh_CN/make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: locale/zh_CN/make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: locale/zh_CN/make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: locale/zh_CN/make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: locale/zh_CN/make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: locale/zh_CN/make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: locale/zh_CN/make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: locale/zh_CN/make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: locale/zh_CN/make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: locale/zh_CN/make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: locale/zh_CN/make/make.md:763 +msgid " build system." +msgstr "" + +#: locale/zh_CN/make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: locale/zh_CN/make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: locale/zh_CN/make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: locale/zh_CN/make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: locale/zh_CN/make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: locale/zh_CN/make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: locale/zh_CN/make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: locale/zh_CN/make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: locale/zh_CN/make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: locale/zh_CN/make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: locale/zh_CN/make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: locale/zh_CN/make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: locale/zh_CN/make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: locale/zh_CN/make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: locale/zh_CN/make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: locale/zh_CN/make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: locale/zh_CN/make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: locale/zh_CN/make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: locale/zh_CN/make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: locale/zh_CN/make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: locale/zh_CN/make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: locale/zh_CN/make/make.md:798 +msgid " direction" +msgstr "" + +#: locale/zh_CN/make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: locale/zh_CN/make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: locale/zh_CN/make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: locale/zh_CN/make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: locale/zh_CN/make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: locale/zh_CN/make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: locale/zh_CN/make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: locale/zh_CN/make/make.md:815 +msgid "do have Make." +msgstr "" + +#: locale/zh_CN/make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: locale/zh_CN/make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: locale/zh_CN/make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: locale/zh_CN/make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: locale/zh_CN/make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: locale/zh_CN/make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: locale/zh_CN/make/make.md:830 +msgid " Linux:" +msgstr "" + +#: locale/zh_CN/make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: locale/zh_CN/make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: locale/zh_CN/make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: locale/zh_CN/make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: locale/zh_CN/make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: locale/zh_CN/make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: locale/zh_CN/make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: locale/zh_CN/make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: locale/zh_CN/make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: locale/zh_CN/make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: locale/zh_CN/make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: locale/zh_CN/make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: locale/zh_CN/make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: locale/zh_CN/make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: locale/zh_CN/make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: locale/zh_CN/make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: locale/zh_CN/make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: locale/zh_CN/make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: locale/zh_CN/make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: locale/zh_CN/make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: locale/zh_CN/make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: locale/zh_CN/make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: locale/zh_CN/make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: locale/zh_CN/make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: locale/zh_CN/make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: locale/zh_CN/make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: locale/zh_CN/make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: locale/zh_CN/make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: locale/zh_CN/make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: locale/zh_CN/make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: locale/zh_CN/make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: locale/zh_CN/make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: locale/zh_CN/make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: locale/zh_CN/make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: locale/zh_CN/make/make.md:980 +msgid "variable." +msgstr "" + +#: locale/zh_CN/make/make.md:982 +msgid "To build all of this, run" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:44 +#: locale/zh_CN/rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:57 +#: locale/zh_CN/rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:79 +#: locale/zh_CN/version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:80 +#: locale/zh_CN/version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:84 +#: locale/zh_CN/version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:85 +#: locale/zh_CN/version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:86 +#: locale/zh_CN/version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:1 +#: locale/zh_CN/version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:13 +#: locale/zh_CN/open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:6 +#: locale/zh_CN/version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:91 +#: locale/zh_CN/reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:74 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:87 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:100 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:164 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:189 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:209 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:216 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:238 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:252 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:289 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:311 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:315 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:341 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:426 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:430 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:488 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:517 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:521 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:14 +#: locale/zh_CN/reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:15 +#: locale/zh_CN/reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:17 +#: locale/zh_CN/reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:46 +#: locale/zh_CN/reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:105 +#: locale/zh_CN/testing/testing.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:56 +#: locale/zh_CN/testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: locale/zh_CN/reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:1 +#: locale/zh_CN/risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:2 +#: locale/zh_CN/risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:5 +#: locale/zh_CN/risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:9 +#: locale/zh_CN/risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:11 +#: locale/zh_CN/risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:13 +#: locale/zh_CN/risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:15 +#: locale/zh_CN/risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:17 +#: locale/zh_CN/risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:25 +#: locale/zh_CN/risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + +#: locale/zh_CN/testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: locale/zh_CN/testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: locale/zh_CN/testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: locale/zh_CN/testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: locale/zh_CN/testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: locale/zh_CN/testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:76 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: locale/zh_CN/testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: locale/zh_CN/testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: locale/zh_CN/testing/testing.md:85 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: locale/zh_CN/testing/testing.md:97 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: locale/zh_CN/testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:106 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: locale/zh_CN/testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: locale/zh_CN/testing/testing.md:111 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: locale/zh_CN/testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: locale/zh_CN/testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: locale/zh_CN/testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: locale/zh_CN/testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:122 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: locale/zh_CN/testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: locale/zh_CN/testing/testing.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: locale/zh_CN/testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: locale/zh_CN/testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: locale/zh_CN/testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: locale/zh_CN/testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: locale/zh_CN/testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: locale/zh_CN/testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: locale/zh_CN/testing/testing.md:139 +#: locale/zh_CN/testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: locale/zh_CN/testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: locale/zh_CN/testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: locale/zh_CN/testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: locale/zh_CN/testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: locale/zh_CN/testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:154 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: locale/zh_CN/testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: locale/zh_CN/testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: locale/zh_CN/testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: locale/zh_CN/testing/testing.md:165 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: locale/zh_CN/testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: locale/zh_CN/testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: locale/zh_CN/testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: locale/zh_CN/testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: locale/zh_CN/testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: locale/zh_CN/testing/testing.md:179 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: locale/zh_CN/testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:184 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: locale/zh_CN/testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: locale/zh_CN/testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: locale/zh_CN/testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: locale/zh_CN/testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:239 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: locale/zh_CN/testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:246 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: locale/zh_CN/testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:267 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: locale/zh_CN/testing/testing.md:270 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: locale/zh_CN/testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: locale/zh_CN/testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: locale/zh_CN/testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: locale/zh_CN/testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:297 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: locale/zh_CN/testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: locale/zh_CN/testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:325 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:334 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: locale/zh_CN/testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: locale/zh_CN/testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: locale/zh_CN/testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:353 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: locale/zh_CN/testing/testing.md:360 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: locale/zh_CN/testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: locale/zh_CN/testing/testing.md:369 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: locale/zh_CN/testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: locale/zh_CN/testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: locale/zh_CN/testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: locale/zh_CN/testing/testing.md:395 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: locale/zh_CN/testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: locale/zh_CN/testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: locale/zh_CN/testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:467 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: locale/zh_CN/testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: locale/zh_CN/testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: locale/zh_CN/testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:480 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: locale/zh_CN/testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: locale/zh_CN/testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: locale/zh_CN/testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: locale/zh_CN/testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: locale/zh_CN/testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: locale/zh_CN/testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:516 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: locale/zh_CN/testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: locale/zh_CN/testing/testing.md:523 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: locale/zh_CN/testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: locale/zh_CN/testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: locale/zh_CN/testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: locale/zh_CN/testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:537 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:550 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: locale/zh_CN/testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: locale/zh_CN/testing/testing.md:557 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: locale/zh_CN/testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: locale/zh_CN/testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: locale/zh_CN/testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: locale/zh_CN/testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: locale/zh_CN/testing/testing.md:574 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: locale/zh_CN/testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: locale/zh_CN/testing/testing.md:579 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: locale/zh_CN/testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: locale/zh_CN/testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:618 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: locale/zh_CN/testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: locale/zh_CN/testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:632 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: locale/zh_CN/testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:643 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: locale/zh_CN/testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: locale/zh_CN/testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: locale/zh_CN/testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: locale/zh_CN/testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: locale/zh_CN/testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: locale/zh_CN/testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: locale/zh_CN/testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: locale/zh_CN/testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: locale/zh_CN/testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: locale/zh_CN/testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: locale/zh_CN/testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: locale/zh_CN/testing/testing.md:705 +#: locale/zh_CN/testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:726 +#: locale/zh_CN/testing/testing.md:731 +#: locale/zh_CN/testing/testing.md:737 +#: locale/zh_CN/testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:93 +#: locale/zh_CN/version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:142 +#: locale/zh_CN/version_control/version_control.md:183 +#: locale/zh_CN/version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:150 +#: locale/zh_CN/version_control/version_control.md:235 +#: locale/zh_CN/version_control/version_control.md:301 +#: locale/zh_CN/version_control/version_control.md:343 +#: locale/zh_CN/version_control/version_control.md:406 +#: locale/zh_CN/version_control/version_control.md:447 +#: locale/zh_CN/version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:155 +#: locale/zh_CN/version_control/version_control.md:241 +#: locale/zh_CN/version_control/version_control.md:305 +#: locale/zh_CN/version_control/version_control.md:352 +#: locale/zh_CN/version_control/version_control.md:410 +#: locale/zh_CN/version_control/version_control.md:473 +#: locale/zh_CN/version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:160 +#: locale/zh_CN/version_control/version_control.md:251 +#: locale/zh_CN/version_control/version_control.md:313 +#: locale/zh_CN/version_control/version_control.md:370 +#: locale/zh_CN/version_control/version_control.md:415 +#: locale/zh_CN/version_control/version_control.md:493 +#: locale/zh_CN/version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:216 +#: locale/zh_CN/version_control/version_control.md:266 +#: locale/zh_CN/version_control/version_control.md:334 +#: locale/zh_CN/version_control/version_control.md:396 +#: locale/zh_CN/version_control/version_control.md:438 +#: locale/zh_CN/version_control/version_control.md:513 +#: locale/zh_CN/version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:578 +#: locale/zh_CN/version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/locale.pot b/book/content/po/locale.pot new file mode 100644 index 00000000000..0ca44950066 --- /dev/null +++ b/book/content/po/locale.pot @@ -0,0 +1,18074 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:3 +#: locale/zh_CN/binderhub/binderhub.md:3 +#: locale/zh_CN/credit/credit.md:11 +#: locale/zh_CN/make/make.md:3 +#: locale/zh_CN/open_research/open_research.md:3 +#: locale/zh_CN/rdm/rdm.md:3 +#: locale/zh_CN/reproducibility/reproducibility.md:3 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:3 +#: locale/zh_CN/version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:6 +#: locale/zh_CN/binderhub/binderhub.md:28 +#: locale/zh_CN/collaborating_github/collaborating_github.md:11 +#: locale/zh_CN/continuous_integration/continuous_integration.md:44 +#: locale/zh_CN/credit/credit.md:28 +#: locale/zh_CN/make/make.md:40 +#: locale/zh_CN/open_research/open_research.md:65 +#: locale/zh_CN/rdm/rdm.md:53 +#: locale/zh_CN/reproducibility/reproducibility.md:13 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:77 +#: locale/zh_CN/reviewing/reviewing.md:8 +#: locale/zh_CN/risk_assessment/risk_assessment.md:27 +#: locale/zh_CN/testing/testing.md:53 +#: locale/zh_CN/version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:15 +#: locale/zh_CN/binderhub/binderhub.md:36 +#: locale/zh_CN/continuous_integration/continuous_integration.md:49 +#: locale/zh_CN/credit/credit.md:32 +#: locale/zh_CN/rdm/rdm.md:64 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:107 +#: locale/zh_CN/reviewing/01/how_helpful.md:1 +#: locale/zh_CN/testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:35 +#: locale/zh_CN/continuous_integration/continuous_integration.md:371 +#: locale/zh_CN/credit/credit.md:105 +#: locale/zh_CN/rdm/rdm.md:486 +#: locale/zh_CN/reproducible_environments/07/checklist.md:3 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:4 +#: locale/zh_CN/testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:36 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:38 +#: locale/zh_CN/continuous_integration/continuous_integration.md:388 +#: locale/zh_CN/open_research/07/resources.md:34 +#: locale/zh_CN/rdm/rdm.md:507 +#: locale/zh_CN/reproducible_environments/08/resources.md:3 +#: locale/zh_CN/reviewing/04/checklists_bib.md:38 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:7 +#: locale/zh_CN/testing/testing.md:656 +#: locale/zh_CN/version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:39 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:41 +#: locale/zh_CN/binderhub/binderhub.md:136 +#: locale/zh_CN/continuous_integration/continuous_integration.md:393 +#: locale/zh_CN/credit/credit.md:127 +#: locale/zh_CN/open_research/07/resources.md:38 +#: locale/zh_CN/rdm/rdm.md:512 +#: locale/zh_CN/reproducible_environments/08/resources.md:9 +#: locale/zh_CN/reviewing/04/checklists_bib.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:10 +#: locale/zh_CN/testing/testing.md:661 +#: locale/zh_CN/version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:42 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:45 +#: locale/zh_CN/binderhub/binderhub.md:144 +#: locale/zh_CN/continuous_integration/continuous_integration.md:402 +#: locale/zh_CN/open_research/07/resources.md:46 +#: locale/zh_CN/rdm/rdm.md:519 +#: locale/zh_CN/reproducible_environments/08/resources.md:15 +#: locale/zh_CN/reviewing/04/checklists_bib.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:14 +#: locale/zh_CN/testing/testing.md:666 +#: locale/zh_CN/version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:48 +#: locale/zh_CN/binderhub/binderhub.md:158 +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:9 +#: locale/zh_CN/continuous_integration/continuous_integration.md:417 +#: locale/zh_CN/open_research/07/resources.md:67 +#: locale/zh_CN/rdm/rdm.md:529 +#: locale/zh_CN/reproducibility/04/resources.md:10 +#: locale/zh_CN/reproducible_environments/08/resources.md:37 +#: locale/zh_CN/reviewing/04/checklists_bib.md:54 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:17 +#: locale/zh_CN/testing/testing.md:701 +#: locale/zh_CN/version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:49 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:5 +#: locale/zh_CN/continuous_integration/continuous_integration.md:3 +#: locale/zh_CN/make/make.md:5 +#: locale/zh_CN/open_research/open_research.md:5 +#: locale/zh_CN/reviewing/reviewing.md:3 +#: locale/zh_CN/version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:10 +#: locale/zh_CN/rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:12 +#: locale/zh_CN/make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:30 +msgid "这章将会讨论" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:6 +#: locale/zh_CN/testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:4 +#: locale/zh_CN/reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:10 +#: locale/zh_CN/make/make.md:12 +#: locale/zh_CN/open_research/open_research.md:11 +#: locale/zh_CN/reproducibility/reproducibility.md:6 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:15 +#: locale/zh_CN/testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:12 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:43 +#: locale/zh_CN/rdm/rdm.md:51 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:75 +#: locale/zh_CN/reviewing/reviewing.md:7 +#: locale/zh_CN/testing/testing.md:52 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:153 +#: locale/zh_CN/continuous_integration/continuous_integration.md:158 +#: locale/zh_CN/version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:370 +#: locale/zh_CN/rdm/rdm.md:484 +#: locale/zh_CN/reproducible_environments/07/checklist.md:1 +#: locale/zh_CN/testing/testing.md:627 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:387 +#: locale/zh_CN/reproducible_environments/08/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:37 +#: locale/zh_CN/testing/testing.md:655 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:392 +#: locale/zh_CN/reproducible_environments/08/resources.md:7 +#: locale/zh_CN/reviewing/04/checklists_bib.md:42 +#: locale/zh_CN/testing/testing.md:660 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:401 +#: locale/zh_CN/reproducible_environments/08/resources.md:13 +#: locale/zh_CN/reviewing/04/checklists_bib.md:45 +#: locale/zh_CN/testing/testing.md:665 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:416 +#: locale/zh_CN/rdm/rdm.md:527 +#: locale/zh_CN/reproducible_environments/08/resources.md:35 +#: locale/zh_CN/reviewing/04/checklists_bib.md:53 +#: locale/zh_CN/testing/testing.md:700 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + +#: locale/zh_CN/credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:3 +#: locale/zh_CN/credit/credit.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:21 +#: locale/zh_CN/open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: locale/zh_CN/credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: locale/zh_CN/credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: locale/zh_CN/credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: locale/zh_CN/credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: locale/zh_CN/credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: locale/zh_CN/credit/credit.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: locale/zh_CN/credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: locale/zh_CN/credit/credit.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:60 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: locale/zh_CN/credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: locale/zh_CN/credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: locale/zh_CN/credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: locale/zh_CN/credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: locale/zh_CN/credit/credit.md:70 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: locale/zh_CN/credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:82 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:84 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: locale/zh_CN/credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: locale/zh_CN/credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: locale/zh_CN/credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: locale/zh_CN/credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: locale/zh_CN/credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: locale/zh_CN/credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: locale/zh_CN/credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: locale/zh_CN/credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: locale/zh_CN/credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: locale/zh_CN/credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: locale/zh_CN/credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: locale/zh_CN/credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: locale/zh_CN/credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: locale/zh_CN/credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: locale/zh_CN/credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: locale/zh_CN/credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:125 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:132 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:134 +msgid "" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + +#: locale/zh_CN/make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: locale/zh_CN/make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: locale/zh_CN/make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: locale/zh_CN/make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: locale/zh_CN/make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: locale/zh_CN/make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: locale/zh_CN/make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: locale/zh_CN/make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: locale/zh_CN/make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: locale/zh_CN/make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: locale/zh_CN/make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: locale/zh_CN/make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: locale/zh_CN/make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: locale/zh_CN/make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: locale/zh_CN/make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: locale/zh_CN/make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: locale/zh_CN/make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: locale/zh_CN/make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: locale/zh_CN/make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: locale/zh_CN/make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: locale/zh_CN/make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: locale/zh_CN/make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: locale/zh_CN/make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: locale/zh_CN/make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: locale/zh_CN/make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: locale/zh_CN/make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: locale/zh_CN/make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:54 +msgid "A " +msgstr "" + +#: locale/zh_CN/make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: locale/zh_CN/make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: locale/zh_CN/make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: locale/zh_CN/make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: locale/zh_CN/make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: locale/zh_CN/make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: locale/zh_CN/make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: locale/zh_CN/make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: locale/zh_CN/make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: locale/zh_CN/make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: locale/zh_CN/make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: locale/zh_CN/make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: locale/zh_CN/make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: locale/zh_CN/make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: locale/zh_CN/make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: locale/zh_CN/make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: locale/zh_CN/make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: locale/zh_CN/make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: locale/zh_CN/make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: locale/zh_CN/make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: locale/zh_CN/make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: locale/zh_CN/make/make.md:86 +msgid " control." +msgstr "" + +#: locale/zh_CN/make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: locale/zh_CN/make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: locale/zh_CN/make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: locale/zh_CN/make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: locale/zh_CN/make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: locale/zh_CN/make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: locale/zh_CN/make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: locale/zh_CN/make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: locale/zh_CN/make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: locale/zh_CN/make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: locale/zh_CN/make/make.md:100 +#: locale/zh_CN/make/make.md:250 +msgid "follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: locale/zh_CN/make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: locale/zh_CN/make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: locale/zh_CN/make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: locale/zh_CN/make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: locale/zh_CN/make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: locale/zh_CN/make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: locale/zh_CN/make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: locale/zh_CN/make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: locale/zh_CN/make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: locale/zh_CN/make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: locale/zh_CN/make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: locale/zh_CN/make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: locale/zh_CN/make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: locale/zh_CN/make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: locale/zh_CN/make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: locale/zh_CN/make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: locale/zh_CN/make/make.md:145 +msgid "**report**." +msgstr "" + +#: locale/zh_CN/make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: locale/zh_CN/make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: locale/zh_CN/make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: locale/zh_CN/make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: locale/zh_CN/make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: locale/zh_CN/make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: locale/zh_CN/make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: locale/zh_CN/make/make.md:168 +msgid "following contents:" +msgstr "" + +#: locale/zh_CN/make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: locale/zh_CN/make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: locale/zh_CN/make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: locale/zh_CN/make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: locale/zh_CN/make/make.md:192 +msgid "will be built." +msgstr "" + +#: locale/zh_CN/make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: locale/zh_CN/make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: locale/zh_CN/make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: locale/zh_CN/make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: locale/zh_CN/make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: locale/zh_CN/make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: locale/zh_CN/make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: locale/zh_CN/make/make.md:201 +msgid "change." +msgstr "" + +#: locale/zh_CN/make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: locale/zh_CN/make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: locale/zh_CN/make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: locale/zh_CN/make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: locale/zh_CN/make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: locale/zh_CN/make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: locale/zh_CN/make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: locale/zh_CN/make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: locale/zh_CN/make/make.md:213 +msgid "the following:" +msgstr "" + +#: locale/zh_CN/make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: locale/zh_CN/make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: locale/zh_CN/make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: locale/zh_CN/make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: locale/zh_CN/make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: locale/zh_CN/make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: locale/zh_CN/make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:232 +msgid "The " +msgstr "" + +#: locale/zh_CN/make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: locale/zh_CN/make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: locale/zh_CN/make/make.md:235 +msgid "top!" +msgstr "" + +#: locale/zh_CN/make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: locale/zh_CN/make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: locale/zh_CN/make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: locale/zh_CN/make/make.md:244 +msgid " make the report." +msgstr "" + +#: locale/zh_CN/make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: locale/zh_CN/make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: locale/zh_CN/make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: locale/zh_CN/make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: locale/zh_CN/make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: locale/zh_CN/make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: locale/zh_CN/make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: locale/zh_CN/make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: locale/zh_CN/make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: locale/zh_CN/make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: locale/zh_CN/make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: locale/zh_CN/make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: locale/zh_CN/make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: locale/zh_CN/make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: locale/zh_CN/make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: locale/zh_CN/make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: locale/zh_CN/make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: locale/zh_CN/make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: locale/zh_CN/make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: locale/zh_CN/make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: locale/zh_CN/make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: locale/zh_CN/make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: locale/zh_CN/make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: locale/zh_CN/make/make.md:302 +msgid "targets:" +msgstr "" + +#: locale/zh_CN/make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: locale/zh_CN/make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: locale/zh_CN/make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: locale/zh_CN/make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: locale/zh_CN/make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: locale/zh_CN/make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: locale/zh_CN/make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: locale/zh_CN/make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: locale/zh_CN/make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: locale/zh_CN/make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: locale/zh_CN/make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: locale/zh_CN/make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: locale/zh_CN/make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: locale/zh_CN/make/make.md:345 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: locale/zh_CN/make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: locale/zh_CN/make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: locale/zh_CN/make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: locale/zh_CN/make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: locale/zh_CN/make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: locale/zh_CN/make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: locale/zh_CN/make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: locale/zh_CN/make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: locale/zh_CN/make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: locale/zh_CN/make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:382 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: locale/zh_CN/make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: locale/zh_CN/make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: locale/zh_CN/make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: locale/zh_CN/make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: locale/zh_CN/make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: locale/zh_CN/make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: locale/zh_CN/make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: locale/zh_CN/make/make.md:413 +msgid "report!" +msgstr "" + +#: locale/zh_CN/make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: locale/zh_CN/make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: locale/zh_CN/make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: locale/zh_CN/make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: locale/zh_CN/make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: locale/zh_CN/make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: locale/zh_CN/make/make.md:425 +msgid "branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: locale/zh_CN/make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: locale/zh_CN/make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:454 +msgid "figures." +msgstr "" + +#: locale/zh_CN/make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: locale/zh_CN/make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: locale/zh_CN/make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: locale/zh_CN/make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: locale/zh_CN/make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: locale/zh_CN/make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: locale/zh_CN/make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: locale/zh_CN/make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: locale/zh_CN/make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: locale/zh_CN/make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: locale/zh_CN/make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: locale/zh_CN/make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: locale/zh_CN/make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: locale/zh_CN/make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: locale/zh_CN/make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: locale/zh_CN/make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: locale/zh_CN/make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: locale/zh_CN/make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: locale/zh_CN/make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: locale/zh_CN/make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: locale/zh_CN/make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: locale/zh_CN/make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: locale/zh_CN/make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: locale/zh_CN/make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: locale/zh_CN/make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: locale/zh_CN/make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: locale/zh_CN/make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: locale/zh_CN/make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: locale/zh_CN/make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: locale/zh_CN/make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: locale/zh_CN/make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: locale/zh_CN/make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: locale/zh_CN/make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: locale/zh_CN/make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: locale/zh_CN/make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: locale/zh_CN/make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: locale/zh_CN/make/make.md:567 +#: locale/zh_CN/make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: locale/zh_CN/make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: locale/zh_CN/make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: locale/zh_CN/make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: locale/zh_CN/make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: locale/zh_CN/make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: locale/zh_CN/make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: locale/zh_CN/make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: locale/zh_CN/make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: locale/zh_CN/make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: locale/zh_CN/make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: locale/zh_CN/make/make.md:589 +msgid "you could add:" +msgstr "" + +#: locale/zh_CN/make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: locale/zh_CN/make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: locale/zh_CN/make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: locale/zh_CN/make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: locale/zh_CN/make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: locale/zh_CN/make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: locale/zh_CN/make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: locale/zh_CN/make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: locale/zh_CN/make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: locale/zh_CN/make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: locale/zh_CN/make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: locale/zh_CN/make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: locale/zh_CN/make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: locale/zh_CN/make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: locale/zh_CN/make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: locale/zh_CN/make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: locale/zh_CN/make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: locale/zh_CN/make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: locale/zh_CN/make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: locale/zh_CN/make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: locale/zh_CN/make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: locale/zh_CN/make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: locale/zh_CN/make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: locale/zh_CN/make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: locale/zh_CN/make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: locale/zh_CN/make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: locale/zh_CN/make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: locale/zh_CN/make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: locale/zh_CN/make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: locale/zh_CN/make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: locale/zh_CN/make/make.md:645 +msgid "repository: " +msgstr "" + +#: locale/zh_CN/make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: locale/zh_CN/make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: locale/zh_CN/make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: locale/zh_CN/make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: locale/zh_CN/make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: locale/zh_CN/make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: locale/zh_CN/make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: locale/zh_CN/make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: locale/zh_CN/make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: locale/zh_CN/make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: locale/zh_CN/make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: locale/zh_CN/make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: locale/zh_CN/make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: locale/zh_CN/make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: locale/zh_CN/make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: locale/zh_CN/make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: locale/zh_CN/make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: locale/zh_CN/make/make.md:674 +msgid " filenames." +msgstr "" + +#: locale/zh_CN/make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: locale/zh_CN/make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: locale/zh_CN/make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: locale/zh_CN/make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: locale/zh_CN/make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: locale/zh_CN/make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: locale/zh_CN/make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: locale/zh_CN/make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: locale/zh_CN/make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: locale/zh_CN/make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: locale/zh_CN/make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: locale/zh_CN/make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: locale/zh_CN/make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: locale/zh_CN/make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: locale/zh_CN/make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: locale/zh_CN/make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: locale/zh_CN/make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: locale/zh_CN/make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: locale/zh_CN/make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: locale/zh_CN/make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: locale/zh_CN/make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: locale/zh_CN/make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: locale/zh_CN/make/make.md:717 +msgid " complex builds." +msgstr "" + +#: locale/zh_CN/make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: locale/zh_CN/make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: locale/zh_CN/make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: locale/zh_CN/make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: locale/zh_CN/make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: locale/zh_CN/make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: locale/zh_CN/make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: locale/zh_CN/make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: locale/zh_CN/make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: locale/zh_CN/make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: locale/zh_CN/make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: locale/zh_CN/make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: locale/zh_CN/make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: locale/zh_CN/make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: locale/zh_CN/make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: locale/zh_CN/make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: locale/zh_CN/make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: locale/zh_CN/make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: locale/zh_CN/make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: locale/zh_CN/make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: locale/zh_CN/make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: locale/zh_CN/make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: locale/zh_CN/make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: locale/zh_CN/make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: locale/zh_CN/make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: locale/zh_CN/make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: locale/zh_CN/make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: locale/zh_CN/make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: locale/zh_CN/make/make.md:763 +msgid " build system." +msgstr "" + +#: locale/zh_CN/make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: locale/zh_CN/make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: locale/zh_CN/make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: locale/zh_CN/make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: locale/zh_CN/make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: locale/zh_CN/make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: locale/zh_CN/make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: locale/zh_CN/make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: locale/zh_CN/make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: locale/zh_CN/make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: locale/zh_CN/make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: locale/zh_CN/make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: locale/zh_CN/make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: locale/zh_CN/make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: locale/zh_CN/make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: locale/zh_CN/make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: locale/zh_CN/make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: locale/zh_CN/make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: locale/zh_CN/make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: locale/zh_CN/make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: locale/zh_CN/make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: locale/zh_CN/make/make.md:798 +msgid " direction" +msgstr "" + +#: locale/zh_CN/make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: locale/zh_CN/make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: locale/zh_CN/make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: locale/zh_CN/make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: locale/zh_CN/make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: locale/zh_CN/make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: locale/zh_CN/make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: locale/zh_CN/make/make.md:815 +msgid "do have Make." +msgstr "" + +#: locale/zh_CN/make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: locale/zh_CN/make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: locale/zh_CN/make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: locale/zh_CN/make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: locale/zh_CN/make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: locale/zh_CN/make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: locale/zh_CN/make/make.md:830 +msgid " Linux:" +msgstr "" + +#: locale/zh_CN/make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: locale/zh_CN/make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: locale/zh_CN/make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: locale/zh_CN/make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: locale/zh_CN/make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: locale/zh_CN/make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: locale/zh_CN/make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: locale/zh_CN/make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: locale/zh_CN/make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: locale/zh_CN/make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: locale/zh_CN/make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: locale/zh_CN/make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: locale/zh_CN/make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: locale/zh_CN/make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: locale/zh_CN/make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: locale/zh_CN/make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: locale/zh_CN/make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: locale/zh_CN/make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: locale/zh_CN/make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: locale/zh_CN/make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: locale/zh_CN/make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: locale/zh_CN/make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: locale/zh_CN/make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: locale/zh_CN/make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: locale/zh_CN/make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: locale/zh_CN/make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: locale/zh_CN/make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: locale/zh_CN/make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: locale/zh_CN/make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: locale/zh_CN/make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: locale/zh_CN/make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: locale/zh_CN/make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: locale/zh_CN/make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: locale/zh_CN/make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: locale/zh_CN/make/make.md:980 +msgid "variable." +msgstr "" + +#: locale/zh_CN/make/make.md:982 +msgid "To build all of this, run" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:44 +#: locale/zh_CN/rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:57 +#: locale/zh_CN/rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:79 +#: locale/zh_CN/version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:80 +#: locale/zh_CN/version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:84 +#: locale/zh_CN/version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:85 +#: locale/zh_CN/version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:86 +#: locale/zh_CN/version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:1 +#: locale/zh_CN/version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:13 +#: locale/zh_CN/open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:6 +#: locale/zh_CN/version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:91 +#: locale/zh_CN/reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:74 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:87 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:100 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:164 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:189 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:209 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:216 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:238 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:252 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:289 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:311 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:315 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:341 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:426 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:430 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:488 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:517 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:521 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:14 +#: locale/zh_CN/reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:15 +#: locale/zh_CN/reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:17 +#: locale/zh_CN/reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:46 +#: locale/zh_CN/reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:105 +#: locale/zh_CN/testing/testing.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:56 +#: locale/zh_CN/testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: locale/zh_CN/reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:1 +#: locale/zh_CN/risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:2 +#: locale/zh_CN/risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:5 +#: locale/zh_CN/risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:9 +#: locale/zh_CN/risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:11 +#: locale/zh_CN/risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:13 +#: locale/zh_CN/risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:15 +#: locale/zh_CN/risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:17 +#: locale/zh_CN/risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:25 +#: locale/zh_CN/risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + +#: locale/zh_CN/testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: locale/zh_CN/testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: locale/zh_CN/testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: locale/zh_CN/testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: locale/zh_CN/testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: locale/zh_CN/testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:76 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: locale/zh_CN/testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: locale/zh_CN/testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: locale/zh_CN/testing/testing.md:85 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: locale/zh_CN/testing/testing.md:97 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: locale/zh_CN/testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:106 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: locale/zh_CN/testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: locale/zh_CN/testing/testing.md:111 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: locale/zh_CN/testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: locale/zh_CN/testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: locale/zh_CN/testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: locale/zh_CN/testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:122 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: locale/zh_CN/testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: locale/zh_CN/testing/testing.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: locale/zh_CN/testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: locale/zh_CN/testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: locale/zh_CN/testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: locale/zh_CN/testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: locale/zh_CN/testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: locale/zh_CN/testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: locale/zh_CN/testing/testing.md:139 +#: locale/zh_CN/testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: locale/zh_CN/testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: locale/zh_CN/testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: locale/zh_CN/testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: locale/zh_CN/testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: locale/zh_CN/testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:154 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: locale/zh_CN/testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: locale/zh_CN/testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: locale/zh_CN/testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: locale/zh_CN/testing/testing.md:165 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: locale/zh_CN/testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: locale/zh_CN/testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: locale/zh_CN/testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: locale/zh_CN/testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: locale/zh_CN/testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: locale/zh_CN/testing/testing.md:179 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: locale/zh_CN/testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:184 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: locale/zh_CN/testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: locale/zh_CN/testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: locale/zh_CN/testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: locale/zh_CN/testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:239 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: locale/zh_CN/testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:246 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: locale/zh_CN/testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:267 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: locale/zh_CN/testing/testing.md:270 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: locale/zh_CN/testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: locale/zh_CN/testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: locale/zh_CN/testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: locale/zh_CN/testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:297 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: locale/zh_CN/testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: locale/zh_CN/testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:325 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:334 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: locale/zh_CN/testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: locale/zh_CN/testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: locale/zh_CN/testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:353 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: locale/zh_CN/testing/testing.md:360 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: locale/zh_CN/testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: locale/zh_CN/testing/testing.md:369 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: locale/zh_CN/testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: locale/zh_CN/testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: locale/zh_CN/testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: locale/zh_CN/testing/testing.md:395 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: locale/zh_CN/testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: locale/zh_CN/testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: locale/zh_CN/testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:467 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: locale/zh_CN/testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: locale/zh_CN/testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: locale/zh_CN/testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:480 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: locale/zh_CN/testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: locale/zh_CN/testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: locale/zh_CN/testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: locale/zh_CN/testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: locale/zh_CN/testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: locale/zh_CN/testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:516 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: locale/zh_CN/testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: locale/zh_CN/testing/testing.md:523 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: locale/zh_CN/testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: locale/zh_CN/testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: locale/zh_CN/testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: locale/zh_CN/testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:537 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:550 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: locale/zh_CN/testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: locale/zh_CN/testing/testing.md:557 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: locale/zh_CN/testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: locale/zh_CN/testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: locale/zh_CN/testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: locale/zh_CN/testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: locale/zh_CN/testing/testing.md:574 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: locale/zh_CN/testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: locale/zh_CN/testing/testing.md:579 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: locale/zh_CN/testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: locale/zh_CN/testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:618 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: locale/zh_CN/testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: locale/zh_CN/testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:632 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: locale/zh_CN/testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:643 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: locale/zh_CN/testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: locale/zh_CN/testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: locale/zh_CN/testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: locale/zh_CN/testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: locale/zh_CN/testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: locale/zh_CN/testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: locale/zh_CN/testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: locale/zh_CN/testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: locale/zh_CN/testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: locale/zh_CN/testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: locale/zh_CN/testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: locale/zh_CN/testing/testing.md:705 +#: locale/zh_CN/testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:726 +#: locale/zh_CN/testing/testing.md:731 +#: locale/zh_CN/testing/testing.md:737 +#: locale/zh_CN/testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:93 +#: locale/zh_CN/version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:142 +#: locale/zh_CN/version_control/version_control.md:183 +#: locale/zh_CN/version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:150 +#: locale/zh_CN/version_control/version_control.md:235 +#: locale/zh_CN/version_control/version_control.md:301 +#: locale/zh_CN/version_control/version_control.md:343 +#: locale/zh_CN/version_control/version_control.md:406 +#: locale/zh_CN/version_control/version_control.md:447 +#: locale/zh_CN/version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:155 +#: locale/zh_CN/version_control/version_control.md:241 +#: locale/zh_CN/version_control/version_control.md:305 +#: locale/zh_CN/version_control/version_control.md:352 +#: locale/zh_CN/version_control/version_control.md:410 +#: locale/zh_CN/version_control/version_control.md:473 +#: locale/zh_CN/version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:160 +#: locale/zh_CN/version_control/version_control.md:251 +#: locale/zh_CN/version_control/version_control.md:313 +#: locale/zh_CN/version_control/version_control.md:370 +#: locale/zh_CN/version_control/version_control.md:415 +#: locale/zh_CN/version_control/version_control.md:493 +#: locale/zh_CN/version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:216 +#: locale/zh_CN/version_control/version_control.md:266 +#: locale/zh_CN/version_control/version_control.md:334 +#: locale/zh_CN/version_control/version_control.md:396 +#: locale/zh_CN/version_control/version_control.md:438 +#: locale/zh_CN/version_control/version_control.md:513 +#: locale/zh_CN/version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:578 +#: locale/zh_CN/version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/locale.tr.po b/book/content/po/locale.tr.po new file mode 100644 index 00000000000..0ca44950066 --- /dev/null +++ b/book/content/po/locale.tr.po @@ -0,0 +1,18074 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:1 +# header +msgid "# Research Planning for Preclinical Scientists" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:3 +#: locale/zh_CN/binderhub/binderhub.md:3 +#: locale/zh_CN/credit/credit.md:11 +#: locale/zh_CN/make/make.md:3 +#: locale/zh_CN/open_research/open_research.md:3 +#: locale/zh_CN/rdm/rdm.md:3 +#: locale/zh_CN/reproducibility/reproducibility.md:3 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:3 +#: locale/zh_CN/version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:4 +msgid "For preclinical scientists – no previous knowledge needed" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:6 +#: locale/zh_CN/binderhub/binderhub.md:28 +#: locale/zh_CN/collaborating_github/collaborating_github.md:11 +#: locale/zh_CN/continuous_integration/continuous_integration.md:44 +#: locale/zh_CN/credit/credit.md:28 +#: locale/zh_CN/make/make.md:40 +#: locale/zh_CN/open_research/open_research.md:65 +#: locale/zh_CN/rdm/rdm.md:53 +#: locale/zh_CN/reproducibility/reproducibility.md:13 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:77 +#: locale/zh_CN/reviewing/reviewing.md:8 +#: locale/zh_CN/risk_assessment/risk_assessment.md:27 +#: locale/zh_CN/testing/testing.md:53 +#: locale/zh_CN/version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:7 +msgid "Society continually debate the use of animals in scientific research. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:8 +msgid "The fundamental questions are whether experiments using animals are morally justifiable and whether the potential benefits outweigh the suffering of those animals?" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:9 +msgid "These questions have been coupled with increasing concern about the poor reproducibility of findings from animal research, due to the impact this has on translation, scientific progress and the use of resources." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:10 +msgid "A question that is not often addressed is how those justified experiments are designed, conducted and analysed." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:11 +msgid "Flawed experimental design, inappropriate statistical analysis and inadequate reporting have been flagged as areas for major concern (Kilkenny et al., 2009 (https://doi.org/10.1371/journal.pone.0007824), Begley et al., 2015 (https://doi.org/10.1161/CIRCRESAHA.114.303819))." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:12 +msgid "It is morally incumbent upon us to ensure that animal experiments are appropriately designed, conducted and analysed otherwise the results are at risk of being unreliable." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:13 +msgid "If the results are unreliable then the animals used have in effect have been wasted (Ioannidis et al., 2014 (https://doi.org/10.1016/S0140-6736(13)62227-8), de Vries et al., 2014 (https://doi.org/10.1093/ilar/ilu043)). " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:15 +#: locale/zh_CN/binderhub/binderhub.md:36 +#: locale/zh_CN/continuous_integration/continuous_integration.md:49 +#: locale/zh_CN/credit/credit.md:32 +#: locale/zh_CN/rdm/rdm.md:64 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:107 +#: locale/zh_CN/reviewing/01/how_helpful.md:1 +#: locale/zh_CN/testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:16 +msgid "Many preclinical researchers do not think of themselves as data scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:17 +msgid "This may be primarily because they work with small datasets." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:18 +msgid "However, there are many common open research themes and this chapter aims to assist preclinical scientists in understanding the why, where, when, and how they can employ open research initiatives, some designed specifically for the use by preclinical scientists." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:19 +# blockquote, which can be cascaded +msgid "> The above sentance may not fit with the structure of the book or flow within these chapters - Nadia" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:21 +# header +msgid "## The Experimental Design Assistant" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:22 +msgid "The National Centre for the Replacement, Refinement and Reduction of Animals in Research (NC3Rs) have a freely accessible web-based tool – The Experimental Design Assistant (EDA; https://eda.nc3rs.org.uk) which aims to help researchers improve the design, conduct, analysis and reporting of animal experiments." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:23 +msgid "Designing experiments with the EDA encourages researchers to consider the sources of bias at the design stages of the experiment before the data are collected, ensuring a rigorous design that is more likely to yield robust findings that can be reproduced." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:24 +msgid "The tool ensures that you have a transparent, clear protocol and plan for statistical analysis which can be scrutinised before collecting data. " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:26 +msgid "**Features of the EDA:**" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:27 +# unordered list +msgid "* A computer-aided design tool to develop a diagram representing the experimental plan" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:28 +# unordered list +msgid "* feedback from an expert system on the experimental plan " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:29 +# unordered list +msgid "* analysis suggestion " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:30 +# unordered list +msgid "* sample size calculation (power analysis)" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:31 +# unordered list +msgid "* randomisation sequence generation " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:32 +# unordered list +msgid "* support for allocation concealment and blinding " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:33 +# unordered list +msgid "* web-based resources to improve knowledge of experimental design and analysis " +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:35 +#: locale/zh_CN/continuous_integration/continuous_integration.md:371 +#: locale/zh_CN/credit/credit.md:105 +#: locale/zh_CN/rdm/rdm.md:486 +#: locale/zh_CN/reproducible_environments/07/checklist.md:3 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:4 +#: locale/zh_CN/testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:36 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:38 +#: locale/zh_CN/continuous_integration/continuous_integration.md:388 +#: locale/zh_CN/open_research/07/resources.md:34 +#: locale/zh_CN/rdm/rdm.md:507 +#: locale/zh_CN/reproducible_environments/08/resources.md:3 +#: locale/zh_CN/reviewing/04/checklists_bib.md:38 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:7 +#: locale/zh_CN/testing/testing.md:656 +#: locale/zh_CN/version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:39 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:41 +#: locale/zh_CN/binderhub/binderhub.md:136 +#: locale/zh_CN/continuous_integration/continuous_integration.md:393 +#: locale/zh_CN/credit/credit.md:127 +#: locale/zh_CN/open_research/07/resources.md:38 +#: locale/zh_CN/rdm/rdm.md:512 +#: locale/zh_CN/reproducible_environments/08/resources.md:9 +#: locale/zh_CN/reviewing/04/checklists_bib.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:10 +#: locale/zh_CN/testing/testing.md:661 +#: locale/zh_CN/version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:42 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:43 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:45 +#: locale/zh_CN/binderhub/binderhub.md:144 +#: locale/zh_CN/continuous_integration/continuous_integration.md:402 +#: locale/zh_CN/open_research/07/resources.md:46 +#: locale/zh_CN/rdm/rdm.md:519 +#: locale/zh_CN/reproducible_environments/08/resources.md:15 +#: locale/zh_CN/reviewing/04/checklists_bib.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:14 +#: locale/zh_CN/testing/testing.md:666 +#: locale/zh_CN/version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:46 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:48 +#: locale/zh_CN/binderhub/binderhub.md:158 +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:9 +#: locale/zh_CN/continuous_integration/continuous_integration.md:417 +#: locale/zh_CN/open_research/07/resources.md:67 +#: locale/zh_CN/rdm/rdm.md:529 +#: locale/zh_CN/reproducibility/04/resources.md:10 +#: locale/zh_CN/reproducible_environments/08/resources.md:37 +#: locale/zh_CN/reviewing/04/checklists_bib.md:54 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:17 +#: locale/zh_CN/testing/testing.md:701 +#: locale/zh_CN/version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: locale/zh_CN/Ethical_Decisions/Planning_Research.md:49 +#: locale/zh_CN/risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:1 +# header +msgid "# BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:5 +#: locale/zh_CN/continuous_integration/continuous_integration.md:3 +#: locale/zh_CN/make/make.md:5 +#: locale/zh_CN/open_research/open_research.md:5 +#: locale/zh_CN/reviewing/reviewing.md:3 +#: locale/zh_CN/version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:6 +msgid "|---|---|---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:7 +msgid "| [Version Control](/version_control/version_control) | Very Important | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:8 +msgid "| [Reproducible Environments](/reproducible_environments/reproducible_environments) | Very Important | Particularly read the section on [Binder](https://the-turing-way.netlify.com/reproducible_environments/reproducible_environments.html#Binder_section). |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:10 +#: locale/zh_CN/rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:12 +#: locale/zh_CN/make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:14 +# unordered list +msgid "- [What is BinderHub and why is it good for Reproducibility?](#what-is-binderhub-and-why-is-it-good-for-reproducibility)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:15 +# unordered list +msgid "- [How does a BinderHub work?](#how-does-a-binderhub-work)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:16 +# unordered list +msgid " - [Compute Resources](#compute-resources)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:17 +# unordered list +msgid " - [Kubernetes](#kubernetes)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:18 +# unordered list +msgid " - [Helm](#helm)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:19 +# unordered list +msgid " - [JupyterHub](#jupyterhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:20 +# unordered list +msgid " - [repo2docker](#repo2docker)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:21 +# unordered list +msgid " - [What happens when a Binder link is clicked?](#what-happens-when-a-binder-link-is-clicked)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:22 +# unordered list +msgid "- [Why would you build your own BinderHub?](#why-would-you-build-your-own-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:23 +# unordered list +msgid " - [Issues you may face when deploying a BinderHub](#issues-you-may-face-when-deploying-a-binderhub)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:24 +# unordered list +msgid "- [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:25 +# unordered list +msgid "- [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:26 +# unordered list +msgid "- [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:30 +msgid "这章将会讨论" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:31 +msgid "We will cover the technologies and tools that BinderHub utilises and the resources you will need to setup your own BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:33 +msgid "This chapter is primarily aimed at Research Software Engineers and IT Services who wish to provide a BinderHub as a service to a group of researchers." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:34 +msgid "Though anyone can build a BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:38 +msgid "Reading this chapter will give you a clearer picture of how Binder services (such as [mybinder.org](https://mybinder.org)) operate, the technologies powering BinderHub and how they interact with one another." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:39 +msgid "This chapter also covers reasons why you might build your own BinderHub, rather than using the public service at mybinder.org." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:41 +# header +msgid "## What is BinderHub and why is it good for Reproducibility?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:43 +msgid "[BinderHub](https://binderhub.readthedocs.io/en/latest/index.html) is a cloud-based technology that can launch a repository of code (from GitHub, GitLab, and others) in a browser window such that the code can be executed and interacted with." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:44 +msgid "A unique URL is generated allowing the interactive code to be easily shared." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:46 +msgid "The purpose of these Binder instances is to promote reproducibility in research projects by encouraging researchers to document their software dependencies and produce fun, interactive environments!" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:48 +msgid "Binder, as a user interface, is useful for reproducibility because the code needs to be version controlled and the computational environment needs to be documented in order to benefit from the functionality of Binder." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:49 +msgid "Each change to the code repository also forces a new build of the Binder instance." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:50 +msgid "This acts as a proxy for continuous integration of the computational environment as the Binder instance will break if the configuration file is not updated." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:52 +msgid "Learn more about Continuous Integration in [this chapter](/continuous_integration/continuous_integration)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:54 +# header +msgid "## How does a BinderHub work?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:56 +msgid "BinderHub relies on different tools and resources in order to create and launch the Binder instances." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:58 +msgid "For more information, see this [high-level explanation of the BinderHub architecture](https://binderhub.readthedocs.io/en/latest/overview.html)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:60 +msgid "| ![/figures/cloud_neutral_binderhub.png](https://zenodo.org/api/iiif/v2/e4125eaf-b456-4097-85fc-6a2e80482d1c:96c70193-2f9e-442d-8cf8-21485d8864e1:1728_TURI_Book%20sprint_45%20repo2docker_040619_v2_MK.jpg/full/750,/0/default.jpg) |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:61 +msgid "|:---:|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:62 +msgid "| A representation of the BinderHub architecture. This image was created by [Scriberia](http://www.scriberia.co.uk/) for The Turing Way community and is used under a CC-BY licence. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:64 +# header +msgid "### Compute Resources" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:66 +msgid "BinderHub is cloud-neutral which means it can be deployed on any cloud platform." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:67 +msgid "Therefore, the minimum requirement is a subscription to a cloud platform of your choosing." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:69 +msgid "In fact, BinderHub is not dependent on cloud-hosting at all and can be deployed onto an on-premise computing system." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:71 +# header +msgid "### Kubernetes" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:73 +msgid "[Kubernetes](https://kubernetes.io/) is a system for automating deployment, scaling (making more or fewer copies), and management of containers across a compute cluster (it doesn't have to be cloud-based)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:74 +msgid "BinderHub uses Kubernetes to manage the resources requested by the users of the Binder service, and to support the tools that build the environments." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:76 +# header +msgid "### Helm" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:78 +msgid "[Helm](https://helm.sh/) is a package manager for Kubernetes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:79 +msgid "Packages come in the form of *Charts* which are a set of instructions to deploy, upgrade and manage applications running on a Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:80 +msgid "They can make installing and managing Kubernetes applications much easier and specific Charts for projects can be published online." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:81 +msgid "For example, the Helm Chart for BinderHub is available [here](https://jupyterhub.github.io/helm-chart/#development-releases-binderhub)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:83 +# header +msgid "### JupyterHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:85 +msgid "[JupyterHub](https://jupyter.org/hub) is a multi-user server for Jupyter Notebooks and containers alike." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:86 +msgid "In the context of Binder, the JupyterHub's main role is to connect the user's browser to the BinderHub instance running on the Kubernetes cluster." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:87 +msgid "However, the JupyterHub can be further customised to provide greater control over the operation of the BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:89 +# header +msgid "### repo2docker" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:91 +msgid "[repo2docker](https://repo2docker.readthedocs.io/en/latest/?badge=latest) is a tool that automatically builds a Docker image from a code repository given a configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:92 +msgid "This Docker image will contain all of the code, data and resources that are listed in the repository." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:93 +msgid "All the software required to run the code will also be preinstalled from the configuration file." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:95 +msgid "BinderHub can be thought of as thin layer that sits on top of repo2docker and JupyterHub, orchestrating their interactions and resolving URLs." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:97 +# header +msgid "### What happens when a Binder link is clicked?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:99 +# ordered list +msgid "1. The link to the repository is resolved by BinderHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:100 +# ordered list +msgid "2. BinderHub searches for a Docker image relating to the provided reference (for example, git commit hash, branch or tag)." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:101 +# ordered list +msgid "3. **If a Docker image is not found**, BinderHub requests resources from the Kubernetes cluster to run repo2docker to do the following:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:102 +# unordered list +msgid " - Fetch the repository," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:103 +# unordered list +msgid " - Build a Docker image containing the software requested in the configuration file," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:104 +# unordered list +msgid " - Push that image to the Docker registry." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:105 +# ordered list +msgid "4. BinderHub sends the Docker image to JupyterHub." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:106 +# ordered list +msgid "5. JupyterHub requests resources from the Kubernetes cluster to serve the Docker image." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:107 +# ordered list +msgid "6. JupyterHub connects the user's browser to the running Docker environment." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:108 +# ordered list +msgid "7. JupyterHub monitors the container for activity and destroys it after a period of inactivity." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:110 +# header +msgid "## Why would you build your own BinderHub?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:112 +msgid "[mybinder.org](https://mybinder.org/) is the free, public BinderHub that hosts almost 100k Binder launches per week." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:113 +msgid "Why might you want to build your own?" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:115 +msgid "Binder is an open source project maintained by volunteers and as such they ask that users stay within certain computational limitations in order to keep running costs as low as possible whilst still providing a usable service." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:116 +msgid "By hosting your own BinderHub, you can offer your users much more flexible and tailored resources." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:118 +msgid "These customisations could include:" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:120 +# unordered list +msgid "- authentication," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:121 +# unordered list +msgid "- greater computational resources per user," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:122 +# unordered list +msgid "- bespoke library stacks and packages," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:123 +# unordered list +msgid "- allowing access to private repos," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:124 +# unordered list +msgid "- persistent storage for users," +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:125 +# unordered list +msgid "- restrict sharing within a certain institution or team." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:127 +# header +msgid "### Issues you may face when deploying a BinderHub" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:129 +msgid "BinderHubs are becoming increasingly popular amongst universities and research institutes." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:130 +msgid "This is because they can facilitate multiple instances of the same set of notebooks for use in a tutorial or workshop setting." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:132 +msgid "If you are deploying a cloud-hosted BinderHub on behalf of your organisation, you may need specific permissions on your organisation's cloud platform subscription." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:133 +msgid "Which permissions you require will vary based on the cloud platform you have access to and your IT Services policies." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:134 +msgid "At minimum, you'll need to be able to assign [Role Based Access Control (RBAC)](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview) to your resources so they can act autonomously in order to manage user traffic." +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:138 +# unordered list +msgid "- [Binder documentation](https://mybinder.readthedocs.io/en/latest/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:139 +# unordered list +msgid "- [BinderHub documentation](https://binderhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:140 +# unordered list +msgid "- [Zero-to-JupyterHub with Kubernetes documentation](https://zero-to-jupyterhub.readthedocs.io/en/latest/index.html)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:141 +# unordered list +msgid "- [JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:142 +# unordered list +msgid "- [_The Turing Way_ Build a BinderHub Workshop](http://bit.ly/zero-to-binderhub-workshop)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:146 +msgid "| | |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:147 +msgid "|:---|:---|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:148 +msgid "| Docker image | A machine-readable set of instructions to create a specified computational environment.|" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:149 +msgid "| Docker container | An active computational environment executed from a Docker image. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:150 +msgid "| Docker registry | A storage and distribution system for named Docker images. The registry allows Docker users to pull images locally, as well as push new images to the registry (given adequate access permissions when applicable). Such systems are often hosted in the cloud for ease of access. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:151 +msgid "| BinderHub | Technology for hosting reproducible computational environments. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:152 +msgid "| Binder | The user-facing service of a BinderHub. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:153 +msgid "| Kubernetes | Autonomous computational cluster manager. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:154 +msgid "| Helm | A package manager for Kubernetes applications. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:155 +msgid "| JupyterHub | A multi-user server for Jupyter Notebook instances. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:156 +msgid "| repo2docker | A tool to build Docker images from code repositories. |" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:160 +# unordered list +msgid "- **Kubernetes documentation**: [https://kubernetes.io/](https://kubernetes.io/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:161 +# unordered list +msgid "- **Helm documentation**: [https://helm.sh/](https://helm.sh/)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:162 +# unordered list +msgid "- **repo2docker**: [https://repo2docker.readthedocs.io/en/latest/?badge=latest](https://repo2docker.readthedocs.io/en/latest/?badge=latest)" +msgstr "" + +#: locale/zh_CN/binderhub/binderhub.md:163 +# unordered list +msgid "- **Microsoft Azure documentation on Role Based Access Control**: [https://docs.microsoft.com/en-us/azure/role-based-access-control/overview](https://docs.microsoft.com/en-us/azure/role-based-access-control/overview)" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:1 +# header +msgid "## README and project communication" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:3 +msgid "README files are the welcome mat for your project. " +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:4 +msgid "They are the first thing new visitors to your project will see and thus are part of a set of really important documents to make potential contributors feel welcome and invite them to get involved." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:5 +msgid "Your [README file](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/write-a-great-project-readme/) should cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:6 +# unordered list +msgid "* What you are doing, for who, and why." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:7 +# unordered list +msgid "* What makes your project special and exciting." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:8 +# unordered list +msgid "* How to get started." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:9 +# unordered list +msgid "* Where to find key resources." +msgstr "" + +#: locale/zh_CN/collaborating_github/1/readme_communication.md:11 +msgid "An [Open Canvas](https://mozilla.github.io/open-leadership-training-series/articles/opening-your-project/develop-an-open-project-strategy-with-open-canvas/) can be a good tool to help you clarify what you want to achieve with your project and what you should cover in your README." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:1 +# header +msgid "## Roadmapping" +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:3 +msgid "If you plan a larger piece of work, it is very useful to have an outline for the work you need to do and share it with potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:4 +msgid "Your roadmap covers your goal and vision and should include a timeline for tasks that need to be completed, thus helping anyone new to your project to develop an understanding of what is currently happening on the project and what's coming next." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:5 +msgid "A roadmap is also a great tool to highlight dependencies among tasks, helping you to schedule work on them efficiently." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:7 +msgid "Milestones can be really helpful to get to your main goal." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:8 +msgid "Milestones can be organised around project goals, dates, events, or timeframes." +msgstr "" + +#: locale/zh_CN/collaborating_github/2/roadmapping.md:9 +msgid "If you work on GitHub, you can use [GitHub's Project board](https://help.github.com/en/articles/tracking-the-progress-of-your-work-with-project-boards) to manage tasks and issues. " +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:1 +# header +msgid "## Getting contributors" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:3 +msgid "Your project is likely to be better if what you create is used by others and they feed back their ideas for additional features or improvements." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:5 +# header +msgid "### Personas and pathways" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:7 +msgid "A persona is a description of a user of your project or tool." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:8 +msgid "It should describe an imaginary person based on observations and knowledge of real life, and existing or potential users which provide enough detail for someone to imagine the persona's needs and reactions to the project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:10 +msgid "Once you have created personas for your main users, you can imagine how they will interact with your project following these engagement phases:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:12 +# ordered list +msgid "1. Discovery: How they first hear about the project or group." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:13 +# ordered list +msgid "2. First Contact: How they first engage with the project or group, their initial interaction." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:14 +# ordered list +msgid "3. Participation: How they first participate or contribute." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:15 +# ordered list +msgid "4. Sustained Participation: How their contribution or involvement can continue." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:16 +# ordered list +msgid "5. Networked Participation: How they may network within the community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:17 +# ordered list +msgid "6. Leadership: How they may take on some additional responsibility on the project, or begin to lead." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:19 +msgid "For an example persona and its pathway through an open project as well as further resources to help you create your own personas, see the [Mozilla Open leadership training](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/bring-on-contributors-using-personas-and-pathways/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:21 +# header +msgid "### Code of Conduct" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:23 +msgid "If your project is open for individuals to contribute and you grow a community, this community will need to be welcoming and inclusive to thrive." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:24 +msgid "One way to establish guidelines for participating in your project is to create a Code of Conduct or Participating Guidelines." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:25 +msgid "These documents can be used for virtual interactions but also for any events you might host related to your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:26 +msgid "Codes of Conducts serve two main purposes:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:27 +# unordered list +msgid "* Establishing the kind of behaviour encouraged in the community you would like to create as well as clearly outlining unacceptable behaviour." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:28 +# unordered list +msgid "* Outlining the process by which problems or violations of the guidelines will be addressed and who will be in charge of enforcing the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:30 +msgid "Many openly developed projects have a Code of Conduct in place that often is openly licensed and can be re-used and adapted for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:31 +msgid "The [Turing Way Code of Conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md) is one example of a Code of Conduct built on various existing ones and can be adapted further." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:32 +msgid "You can also consult the Mozilla Open Leadership Series [section on codes of conduct](https://mozilla.github.io/open-leadership-training-series/articles/building-communities-of-contributors/write-a-code-of-conduct/) for further guidelines and examples to get started on a code of conduct for your project." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:34 +# header +msgid "### Contributor guidelines" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:36 +msgid "In addition to setting out some ground rules for the behaviour expected when collaborating on your project, you might want to provide some hands-on steps that potential collaborators should follow to add their contributions." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:37 +msgid "Those instructions are laid out in a CONTRIBUTING file (this is an idea borrowed from software engineering where capitalized filenames are the norm for the most important files of a project)." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:38 +msgid "Your audiences for the contributing guidelines are your potential contributors who need to understand what is expected from them, project consumers who need to know how they can remix and re-use your work, and yourself who creates and maintains the file as a key part to outline interactions with your community." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:39 +msgid "Similar to other key documents, is it recommended that you look at examples of contributing guidelines of similar projects and re-use those." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:40 +msgid "Here are a few suggestions of what your contributing guidelines could cover:" +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:41 +# unordered list +msgid "* Your project vision." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:42 +# unordered list +msgid "* A welcome to potential contributors." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:43 +# unordered list +msgid "* Pointers to the Code of Conduct." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:44 +# unordered list +msgid "* A list of other important resources such as the README file or your project's roadmap." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:45 +# unordered list +msgid "* Communication channels where contributors can reach you." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:46 +# unordered list +msgid "* How to submit changes." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:47 +# unordered list +msgid "* Good first bugs or issues to start working on." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:48 +# unordered list +msgid "* How to report a bug." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:49 +# unordered list +msgid "* Your recognition model and how contributions will get acknowledged." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:50 +# unordered list +msgid "* Where to go for help." +msgstr "" + +#: locale/zh_CN/collaborating_github/3/getting_contributors.md:52 +msgid "Have a look at the [Turing Way contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to understand how you can contribute to this book and re-use some ideas for your own project." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:1 +# header +msgid "## GitHub contributor section as your checklist" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:3 +msgid "GitHub encourages collaboration practice in their community guidelines. " +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:4 +msgid "The insights tab of your GitHub project provides a section called \"Community\" that includes a list of recommended documents that your project should have." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:5 +msgid "Those include a README, Code of Conduct, Contributing guidelines, licence, and templates for issues and pull requests." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:7 +msgid "![Community profile on GitHub](/assets/figures/community_profile_github.png)" +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:11 +msgid "This chapter is an abbreviated version of the Mozilla Open Leadership Series material which is licensed under a [Creative Commons Attribution 4.0 licence](https://creativecommons.org/licenses/by/4.0/)." +msgstr "" + +#: locale/zh_CN/collaborating_github/4/checklist_bibliography.md:12 +msgid "The complete Open Leadership Handbook is available at https://mozilla.github.io/open-leadership-training-series/articles/readme/ and is highly recommended it as additional reading." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:1 +# header +msgid "# Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:6 +#: locale/zh_CN/testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:7 +msgid "| -------------|----------|" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:8 +msgid "| [Experience with version control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:13 +# header +msgid "## Why this is useful" +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:15 +msgid "Developing your project or analysis collaboratively on GitHub or GitLab provides a prompter to document your work in detail and it provides a great opportunity to get additional contributors to your idea." +msgstr "" + +#: locale/zh_CN/collaborating_github/collaborating_github.md:16 +msgid "Contributions can be everything from new ideas, to bug reports and actual code contributions." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:1 +# header +msgid "# Continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:4 +#: locale/zh_CN/reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Continuous integration will follow command line instructions" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:6 +msgid "| [Version control](/version_control/version_control) | Necessary | Continuous integration runs every time a new _commit_ is made to your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:7 +msgid "| [Reproducible computational environments](/reproducible_environments/reproducible_environments) | Necessary | Continuous integration runs your tests on a separate computer (usually in the cloud) so you need to set it up in the same way. |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:8 +msgid "| [Testing](/testing/testing) | Very helpful | Continuous integration _tests_ if anything important has changed when you make a change in your project |" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:10 +#: locale/zh_CN/make/make.md:12 +#: locale/zh_CN/open_research/open_research.md:11 +#: locale/zh_CN/reproducibility/reproducibility.md:6 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:15 +#: locale/zh_CN/testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:12 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:13 +# unordered list +msgid "- [How this will help you/ why this is useful](#Why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:14 +# unordered list +msgid " - [What are continuous delivery and continuous deployment?](#What_are_continuous_delivery_and_continuous_deployment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:15 +# unordered list +msgid "- [What is Travis and how does it work?](#What_is_Travis_and_how_does_it_work)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:16 +# unordered list +msgid "- [Setting up continuous integration with Travis](#Setting_up_continuous_integration_with_Travis)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:17 +# unordered list +msgid " - [Basic steps](#Basic_steps)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:18 +# unordered list +msgid " - [Setting up the computational environment](#Setting_up_the_computational_environment)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:19 +# unordered list +msgid " - [Operating system](#Operating_system)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:20 +# unordered list +msgid " - [Programming language](#Programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:21 +# unordered list +msgid " - [Compilers](#Compilers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:22 +# unordered list +msgid " - [Dependencies](#Dependencies)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:23 +# unordered list +msgid " - [Containers](#Containers)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:24 +# unordered list +msgid " - [The .travis.yml script](#The_travis_yml_script)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:25 +# unordered list +msgid " - [After success](#After_success)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:26 +# unordered list +msgid " - [Testing a project against multiple versions of a programming language](#Testing_a_project_against_multiple_versions_of_a_programming_language)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:27 +# unordered list +msgid " - [Testing a project on multiple operating systems](#Testing_a_project_on_multiple_operating_systems)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:28 +# unordered list +msgid " - [Allowing failures](#Allowing_failures)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:29 +# unordered list +msgid "- [Limitations of CI](#Limitations_of_CI)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:30 +# unordered list +msgid "- [Best practise for continuous integration](#Best_practise_for_continuous_integration)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:31 +# unordered list +msgid " - [Small, iterative changes](#Small_iterative_changes)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:32 +# unordered list +msgid " - [Trunk-based development](#Trunk_based_development)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:33 +# unordered list +msgid " - [Keep the building and testing phases fast](#Keep_the_building_and_testing_phases_fast)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:34 +# unordered list +msgid " - [Computational expense](#Computational_expense)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:35 +# unordered list +msgid " - [Dependencies tracking](#Dependencies_tracking)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:36 +# unordered list +msgid " - [Consistency throughout the pipeline](#Consistency_throughout_the_pipeline)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:37 +# unordered list +msgid "- [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:38 +# unordered list +msgid "- [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:39 +# unordered list +msgid "- [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:40 +# unordered list +msgid "- [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:41 +# unordered list +msgid "- [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:43 +#: locale/zh_CN/rdm/rdm.md:51 +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:75 +#: locale/zh_CN/reviewing/reviewing.md:7 +#: locale/zh_CN/testing/testing.md:52 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:46 +msgid "Continuous integration (CI) is the practice of integrating changes to a project made by individuals into a main, shared version frequently (usually multiple times per day). CI software is also typically used to identify any conflicts and bugs that are introduced by changes, so they are found and fixed early, minimizing the effort required to do so. Running tests regularly also saves humans from needing to do it manually. By making users aware of bugs as early as possible researchers (if the project is a research project) do not waste a lot of time doing work that may need to be thrown away, which may be the case if tests are run infrequently and results are produced using faulty code." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:51 +msgid "CI has a number of key benefits:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:53 +# unordered list +msgid "- Helps bugs to be found early, minimizing their damage and making them easier to fix" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:54 +# unordered list +msgid "- Keeps project contributors up to date with each other's work so they can benefit from it as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:55 +# unordered list +msgid "- Encourages users to write tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:56 +# unordered list +msgid "- Automates running of tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:57 +# unordered list +msgid "- Ensures tests are run frequently" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:60 +# header +msgid "## What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:62 +msgid "This chapter demands a strong understanding of version control. The central concepts you will need to recall are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:64 +# unordered list +msgid "- How it can be used to enable people collaborating on a single project to combine their work via merging" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:65 +# unordered list +msgid "- What merge conflicts are and the difficulties they can present" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:66 +# unordered list +msgid "- What GitHub is and how to use it" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:68 +msgid "In brief if a group of researchers are collaborating on a project it is good practise for them to use version control to keep track of their changes over time, and combine their work regularly. If they do not combine (integrate) their work regularly then when they come to do so it is likely to be very difficult as different people may have made contradictory changes." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:70 +msgid "Continuous Integration is a software development practice where members of a team integrate their work frequently, rather than doing work in isolation and merging in large changes at infrequent intervals. In CI usually each person integrates at least daily. Each integration is verified by an automated build (usually including tests) to detect integration errors as quickly as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:72 +msgid "The idea is to minimize the cost of integration by making it an early consideration. Researchers can discover conflicts at the boundaries between new and existing code early, while they are still relatively easy to reconcile. Once the conflict is resolved, work can continue with confidence that the new code honours the requirements of the existing codebase. The goal is to build healthier software by developing and testing in smaller increments. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop more rapidly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:74 +msgid "Integrating code frequently does not, by itself, offer any guarantees about the quality of the new code or functionality. This leads us to the second aspect of CI. When a developer merges code into the main repository, automated processes build a working version of the project. Afterwards, test suites are run against the new build to check whether any bugs were introduced. If either the build or the test phase fails, the team is alerted so that they can work to fix the problem. It is easier to fix a bug in something you wrote a few minutes ago than something you wrote yesterday (or last week, or last month)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:76 +msgid "By ensuring that your code is built and tested regularly CI helps researchers to demonstrate that their code does what it claims to do, and that it does so correctly. Typically, continuous integration servers will also allow build-and-test jobs to run at specific times, so a CRON-like, nightly-build-and-test, can be done, as well as a build-and-test job run on-demand." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:78 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:79 +# header +msgid "### What are continuous delivery and continuous deployment?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:81 +msgid "Technically speaking the above explanation conflates three related concepts, continuous integration, continuous deployment, and continuous delivery. In reality:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:83 +# unordered list +msgid "- Continuous integration focuses on regularly integrating work from individual researchers into a main repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:84 +# unordered list +msgid "- Continuous delivery automates and runs the steps required to build and test the project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:85 +# unordered list +msgid "- Continuous deployment takes this one step further by automatically deploying each time a code change is made." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:87 +msgid "In this chapter this entire process is referred to as continuous integration for the sake of simplicity." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:90 +# header +msgid "## What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:92 +msgid "There are a number of CI tools available, such Circle (tutorials [here](https://circleci.com/docs/2.0/project-walkthrough/) and [here](https://circleci.com/docs/2.0/hello-world/)). A list of other CI tools can be found [here](https://www.software.ac.uk/resources/guides/hosted-continuous-integration). In this chapter we will focus on [Travis](https://travis-ci.org/) because it's free (if your code is openly available), widely used, and well integrated with the version control platform [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:94 +msgid "To use Travis you will need to add a file to your project called `.travis.yml` which describes the computational environment to run the project in, and includes a script to run your tests. See the chapter on reproducible computational environments for more information on them, including writing `.yml` files to specify them. See the chapter on testing for information on writing and automating tests. The .travis.yml file has a number of other capabilities, which will be described [later](#After_success) along with more [detailed instructions](#Setting_up_the_computational_environment) for writing these files." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:96 +msgid "Once Travis has been set up on a project then each time a commit is made it:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:98 +# unordered list +msgid "- Clones a copy of project" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:99 +# unordered list +msgid "- Generates a copy of the computational environment specified in the .travis.yml file in a brand new virtual environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:100 +# unordered list +msgid "- Builds the project within that environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:101 +# unordered list +msgid "- Runs the tests by following the script specified in the .travis.yml file" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:102 +# unordered list +msgid "- Reports the results" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:103 +# unordered list +msgid " - Travis will output the results of every step of building the environment and running the script as a log viewable in your account on the [Travis site](https://travis-ci.org/) (the dark grey box in the figure below)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:104 +# unordered list +msgid " - Travis will attach a badge to the results, green if all steps in the script (which run the tests) pass, red if not. The badge will be yellow whilst Travis is still running. If Travis is unable to generate the computational environment described in the .travis.yml file then it will not proceed further and the badge will be grey. See the figures below which show the passing build badge and failing build badge in the readme of a GitHub repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:105 +# unordered list +msgid " - Travis will also report the results via email (notification settings can be adjusted)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:107 +msgid "Here's what the Travis dashboard of a repository looks like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:109 +msgid "![Travis_build](../figures/Travis_build.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:111 +msgid "Everything's green because the build is passing. Note the \"build passing\" badge at the top. If you click that you will get a popup with a dropdown menu where you can select a way of copying the badge. If you select \"markdown\" and copy and paste the code snippet it outputs into a markdown file in the project, then GitHub will display the badge in that file:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:113 +msgid "![Travis_badge_pass](../figures/Travis_badge_pass.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:115 +msgid "If I deliberately create a bug and commit it then Travis automatically runs, the tests fail, and this badge automatically updates to \"build failing\":" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:117 +msgid "![Travis_badge_fail](../figures/Travis_badge_fail.png)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:119 +msgid "You can use Travis to test your project in multiple computational environments my specifying them in the .travis.yml file. A quick note on Travis vocabulary:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:121 +# unordered list +msgid "- Job - an automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:122 +# unordered list +msgid "- Build - a group of jobs. For example, a build might have two *jobs*, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:124 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:125 +# header +msgid "## Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:128 +# header +msgid "### Basic steps" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:130 +# unordered list +msgid "- Write a `.travis.yml` file and add it to your project." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:131 +# unordered list +msgid "- Upload your project to GitHub if you have not already." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:132 +# unordered list +msgid "- Go to [Travis-ci.com](https://travis-ci.com) and [Sign up with GitHub](https://travis-ci.com/signin)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:133 +# unordered list +msgid "- Accept the Authorization of Travis CI. You'll be redirected to GitHub." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:134 +# unordered list +msgid "- You will see a list of your GitHub repositories with buttons next to them. Click the button next to your project repository to activate Travis on it." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:135 +# unordered list +msgid "- Check the build status page to see if your build passes or fails, according to the return status of the build command by visiting the [Travis CI](https://travis-ci.com/auth) and selecting your repository." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:136 +# unordered list +msgid "- Next time you commit to your repository Travis will run on the updated version of your project and report the results." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:138 +msgid "It's that simple. The rest of this section will describe the different components of the .travis.yml file and how to write them." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:141 +# header +msgid "### Setting up the computational environment" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:143 +msgid "This page on [common build problems](https://docs.travis-ci.com/user/common-build-problems/) is a good place to start troubleshooting if your build is broken." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:145 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:146 +# header +msgid "#### Operating system" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:148 +msgid "Travis CI works with a few different operating systems. In the .travis.yml file define the operating system to run a project on via the os keyword like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:149 +# code block +msgid "```\n" +"os: linux\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:153 +#: locale/zh_CN/continuous_integration/continuous_integration.md:158 +#: locale/zh_CN/version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:154 +# code block +msgid "```\n" +"os: macOS\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:159 +# code block +msgid "```\n" +"os: windows\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:163 +msgid "It is possible to build and test a project on multiple operating systems and against multiple versions of a programming language. This will be not be discussed here as this presents and extra level of complexity and will not be needed in most cases for research, but it is discussed [later](#Testing_a_project_against_multiple_versions_of_a_programming_language)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:165 +msgid "To specify the distribution of an operating system to run the project with use `dist`, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:167 +# code block +msgid "```\n" +"os: linux\n" +"dist: trusty\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:173 +# header +msgid "#### Programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:175 +msgid "Specify the programming language to run your project with using the language keyword, and specify which version of the language to use. So for python2.7 this would look like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:176 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +"- \"2.7\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:181 +msgid "Further information on the programming languages that are compatible with Travis can be found [here](https://docs.travis-ci.com/user/languages/)" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:183 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:184 +# header +msgid "#### Compilers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:186 +msgid "If a compiled language is being used which compiler to run can be specified with the compiler keyword:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:187 +# code block +msgid "```\n" +"compiler:\n" +" - gcc\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:191 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:192 +# header +msgid "#### Dependencies" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:194 +msgid "Not all languages/software are available on all operating systems however they can typically be installed within the .travis.yml file." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:196 +msgid "To install packages that are not included in the standard version of the operating system specified you can include a `before_install` step in your `.travis.yml` along with the necessary code to install them, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:198 +# code block +msgid "```\n" +"before_install:\n" +" - sudo apt-get install -y libxml2-dev\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:202 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:203 +# header +msgid "#### Containers" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:205 +msgid "It is possible to use Docker containers (see the reproducible computational environments chapter) to generate the computational environment by pulling and running the image from the .travis.yml file. If you are doing so you should pull or generate the image (preferably pull to save Travis from having to build the image from scratch) in the before_install step (see above section). Then in the .travis.yml file's script ([see next section](#The_travis_yml_script)) you can run a command to run your tests like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:206 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t image_name command_to_run\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:211 +msgid "So to use pytest to run tests in python files in a container built from an image called a_demo_image" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:212 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:217 +msgid "If you need to run more than one command in your script then you can include a script file within the container which contains those commands. Then the same process shown above can be used to run it, like:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:218 +# code block +msgid "```\n" +"script:\n" +" - sudo docker run -t a_demo_image ./a_script.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:223 +msgid "See [here](https://docs.travis-ci.com/user/docker/) for more information on this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:226 +# header +msgid "### The .travis.yml script" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:228 +msgid "Travis will report that the build has failed if any commands in the script section return an error. Technically any commands can be included in the script, but it is mainly used for running tests. A script does not need to be long or complicated, as demonstrated by this example which uses the pytest command to run tests in python scripts:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:229 +# code block +msgid "```\n" +"script:\n" +"- pytest\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:234 +msgid "If there are steps that need to be done before a project to be considered to be \"fully\" working these should also be included in the script too. Lets say some project needs a figure to be converted to a png file for some reason. The script could include" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:235 +# code block +msgid "```\n" +" - convert figure_name.jpg figure_name.png\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:239 +msgid "If for any reason this cannot be done an error will be returned and the build will be marked as having failed." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:241 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:242 +# header +msgid "### After success" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:244 +msgid "The after success section is much like the script section in that it contains commands to run on the project. The key difference if that the build will not fail if steps in the after success section return errors." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:246 +msgid "The after success section is run after the script, and can be used to automate steps that need to be taken once a build has passed all the tests. Examples of things that can be automated include automatically merging the new version of the project to the master branch in GitHub. Another example is for the code coverage (see testing chapter) to be automatically measured and reported, as shown here:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:247 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.7\"\n" +"\n" +"before_install:\n" +" - pip install coverage\n" +"\n" +"script:\n" +" - pytest\n" +"\n" +"after_success:\n" +" - coverage run main.py\n" +" - coverage report\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:263 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:264 +# header +msgid "### Testing a project against multiple versions of a programming language" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:266 +msgid "When a project is expected to be run on systems with different versions of a programming language you can set Travis to run the tests on each of these versions. For example to test on a variety of versions of python:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:267 +# code block +msgid "```\n" +"language: python\n" +"python:\n" +" - \"2.6\"\n" +" - \"2.7\"\n" +" - \"3.2\"\n" +" - \"3.3\"\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:275 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:276 +# header +msgid "### Testing a project on multiple operating systems" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:278 +msgid "If your code is used on multiple operating systems it should be tested on multiple operating systems. To enable testing on multiple operating systems add multiple entries under the `os` key in your `.travis.yml` file, for example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:279 +# code block +msgid "```\n" +"os:\n" +" - linux\n" +" - osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:285 +msgid "When you test your code on multiple operating systems, be aware of differences that can affect your tests, for example not all tools and programming languages are available on all operating systems. This should be taken into account when writing commands for your script file (or other sections of the .travis.yml file). Also file system behaviour may differ between OSs. Your tests may implicitly rely on these behaviours, and could fail because of them. They are different operating systems, after all." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:287 +msgid "When Travis is running a job it sets the `TRAVIS_OS_NAME` variable which describes the operating system being tested. You can use this to run commands only on specified operating systems like this:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:288 +# code block +msgid "```\n" +" - if [[ \"$TRAVIS_OS_NAME\" == \"osx\" ]]; then command_to_run; fi\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:292 +msgid "It is possible to go further and construct a [build matrix](https://docs.travis-ci.com/user/build-matrix/) to test a the project in a range of computational environments." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:294 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:295 +# header +msgid "#### Allowing failures" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:297 +msgid "To ignore the results of jobs in certain computational environments you can define rows that are allowed to fail in the build matrix. Do this by adding an `allow_failures` section to the .travis.yml file. Allowed failures are items in your build matrix that are allowed to fail without causing the entire build to fail. For example to allow the build to pass even if the job(s) using the osx operating system fail you'd add the following to your `.travis.yml`:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:298 +# code block +msgid "```\n" +"matrix:\n" +" allow_failures:\n" +" - os: osx\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:304 +msgid "This is useful if you ideally want the build to be successful in multiple environments, but not all of them are vital." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:306 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:307 +# header +msgid "## Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:309 +msgid "CI does have its limitations. Firstly it is only as effective at finding bugs as the tests provided to it. If a project contains few or poor tests then it is entirely possible the project will contain bugs the tests do not catch and Travis will report the build as successful." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:311 +msgid "Secondly, depending on the nature of your project there may be security considerations to think about. " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:313 +msgid "Travis CI obfuscates secure environment variables and tokens displayed in by the user interface. The [documentation about encryption keys](https://docs.travis-ci.com/user/encryption-keys/) outlines the build configuration required to set this up. However, if secret information is outputted in the course of running a script (for example in an error message) it may be included in Travis's build logs which may be accessible by others. To prevent leaks like this, secure environment variables and tokens that are longer than three characters are automatically filtered at runtime, effectively removing them from the build log, displaying the string `[secure]` instead. Nevertheless you should rotate your tokens and secrets regularly." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:315 +msgid " However there are still many ways in which secure information can accidentally be exposed. These vary according to what tools you are using and the settings enabled. Some things to look out for are:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:317 +# unordered list +msgid "- Settings which duplicate commands to standard output, such as `set -x` or `set -v` in your bash scripts" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:318 +# unordered list +msgid "- Displaying environment variables, by running `env` or `printenv`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:319 +# unordered list +msgid "- Printing secrets within the code, for example `echo \"$SECRET_KEY\"`" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:320 +# unordered list +msgid "- Git commands like `git fetch` or `git push` may expose tokens or other secure environment variables" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:321 +# unordered list +msgid "- Settings which increase command verbosity" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:323 +msgid "Preventing commands from displaying any output is one way to avoid accidentally displaying any secure information. If there is a particular command that is using secure information you can redirect its output to `/dev/null` to make sure it does not accidentally publish anything, as shown in the following example:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:324 +# code block +msgid "```\n" +"git push url-with-secret >/dev/null 2>&1\n" +"```" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:328 +msgid "If your project is set up such that each time a pull request is made on GitHub Travis tests that pull request there is an additional concern. If your tests require authentication credentials someone could make a pull request with malicious code to expose them. Therefore it is a good idea not to allow pull requests to automatically trigger Travis if you have such authentication requirements." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:330 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:331 +# header +msgid "## Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:333 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:334 +# header +msgid "### Small, iterative changes" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:336 +msgid "One of the most important practices when adopting continuous integration is to encourage project members to make and commit small changes. Small changes minimize the possibility and impact of problems cropping up when they're integrated, which minimises the time and effort cost of integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:338 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:339 +# header +msgid "### Trunk-based development" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:341 +msgid "With trunk-based development, work is done in the main branch of the repository or merged back into the shared repository at frequent intervals. Short-lived feature branches are permissible as long as they represent small changes and are merged back as soon as possible." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:343 +msgid "The idea behind trunk-based development is to avoid large commits that violate of concept of small, iterative changes discussed above. Code is available to peers early so that conflicts can be resolved when their scope is small." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:345 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:346 +# header +msgid "### Keep the building and testing phases fast" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:348 +msgid "Because the build and test steps must be performed frequently, it is essential that these processes be streamlined to minimize the time spent on them. Increases in build time should be treated as a major problem because the impact is compounded by the fact that each commit kicks off a build." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:350 +msgid "When possible, running different sections of the test suite in parallel can help move the build through the pipeline faster. Care should also be taken to make sure the proportion of each type of test makes sense. Unit tests are typically very fast and have minimal maintenance overhead. In contrast, automated system or acceptance testing is often complex and prone to breakage. To account for this, it is often a good idea to rely heavily on unit tests, conduct a fair number of integration tests, and then back off on the number of later, more complex testing." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:352 +# header +msgid "### Computational expense" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:354 +msgid "Some software will require significant compute resource to build and/or run. Examples include weather and climate models. This can make the use of continuous integration impractical as the tests either take too long or use too much resource. Therefore, a compromise needs to be found to balance the risk of incomplete testing against a usable development process." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:356 +msgid "One approach is to use different levels of testing, with different subgroups being required depending on what is being changed. A common broad subgroup can be used in every case, with additional ones being invoked to test certain areas in more detail. This introduces an element of judgement to the testing process, but can be applied successfully." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:358 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:359 +# header +msgid "### Dependencies tracking" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:361 +msgid "Checking for dependency updates should be done regularly. It can save a lot of time, avoiding bugs due to code dependent on deprecated functionality. Services such as [David](https://david-dm.org/) are available for dependency management." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:363 +msgid " " +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:364 +# header +msgid "### Consistency throughout the pipeline" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:366 +msgid "A project should be built once at the beginning of the pipeline, the resulting software should be stored and accessible to later processes without rebuilding. By using the exact same artefact in each phase, you can be certain that you are not introducing inconsistencies as a result of different build tools." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:368 +msgid "Also, the environment defined by the .travis.yml file should reflect the actual environment the code is run in. If that environment is modified don't forget to update the .travis.yml file, otherwise the results Travis returns will not be trustworthy." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:370 +#: locale/zh_CN/rdm/rdm.md:484 +#: locale/zh_CN/reproducible_environments/07/checklist.md:1 +#: locale/zh_CN/testing/testing.md:627 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:373 +# unordered list +msgid "- [ ] Have a project that you collaborate on with at least one other person" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:374 +# unordered list +msgid "- [ ] Put the project on GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:375 +# unordered list +msgid "- [ ] Have project members regularly commit their work to this central repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:376 +# unordered list +msgid "- [ ] That project should have at least some tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:377 +# unordered list +msgid "- [ ] Write a .travis.yml file which:" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:378 +# unordered list +msgid " - [ ] Sets out the operating system the project is run on" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:379 +# unordered list +msgid " - [ ] Defines the programming language and version of that language to run the project with" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:380 +# unordered list +msgid " - [ ] Includes code to install any dependencies required to run the project in a before_install step" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:381 +# unordered list +msgid " - [ ] Contains a script to run the project tests" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:382 +# unordered list +msgid "- [ ] Commit the .travis.yml file to the project's GitHub repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:383 +# unordered list +msgid "- [ ] Go to [travis-ci.com](https://travis-ci.com/) and sign in with GitHub" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:384 +# unordered list +msgid "- [ ] Activate Travis on your project repository" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:385 +# unordered list +msgid "- [ ] Each time a new commit is pushed Travis will run the tests and return the results. If these report that a commit causes test/tests to fail then find and fix the problem as soon as possible" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:387 +#: locale/zh_CN/reproducible_environments/08/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:37 +#: locale/zh_CN/testing/testing.md:655 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:390 +msgid "If you have not already read the testing chapter it is suggested to do so to learn more about the different kinds of tests and their benefits in order to make the most of CI." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:392 +#: locale/zh_CN/reproducible_environments/08/resources.md:7 +#: locale/zh_CN/reviewing/04/checklists_bib.md:42 +#: locale/zh_CN/testing/testing.md:660 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:395 +msgid "Travis offers a great deal of functionality not described here for automating other processes related to the testing and deployment of projects. Look into these, the Travis [documentation](https://docs.travis-ci.com/user/deployment) offers a good starting point for this." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:397 +msgid "A list of example Travis builds and tests for various languages/frameworks is available [here](https://github.com/softwaresaved/build_and_test_examples)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:399 +msgid "Travis's official tutorial is [here](https://docs.travis-ci.com/user/tutorial/). A tutorial focussed on using Travis with R can be found [here](https://juliasilge.com/blog/beginners-guide-to-travis/), tutorials geared towards python can be found [here](https://docs.python-guide.org/scenarios/ci/) and [here](https://docs.travis-ci.com/user/languages/python/)." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:401 +#: locale/zh_CN/reproducible_environments/08/resources.md:13 +#: locale/zh_CN/reviewing/04/checklists_bib.md:45 +#: locale/zh_CN/testing/testing.md:665 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:404 +msgid "**Build:** A group of jobs. For example, a build might have two jobs, each of which tests a project with a different version of a programming language. A build finishes when all of its jobs are finished." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:406 +msgid "**Computational environment:** The environment where a project is run, including the operating system, the software installed on it, and the versions of both." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:408 +msgid "**Continuous integration:** The process of regularly combining the work of project members into a centralised version. Also called CI. CI software typically runs tests on the integrated version of a project to identify conflicts and bugs introduced by the integration." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:410 +msgid "**GitHub:** A widely used version control platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:412 +msgid "**Job:** An automated process that clones your repository into a virtual environment and then carries out a series of phases such as compiling your code and running tests. A job fails if the return code of the script encounters an error." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:414 +msgid "**Travis:** A commonly used continuous integration platform." +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:416 +#: locale/zh_CN/rdm/rdm.md:527 +#: locale/zh_CN/reproducible_environments/08/resources.md:35 +#: locale/zh_CN/reviewing/04/checklists_bib.md:53 +#: locale/zh_CN/testing/testing.md:700 +msgid "" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:419 +# header +msgid "### Materials used: What is continuous integration?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:421 +# unordered list +msgid "- [What is CI](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:422 +# unordered list +msgid "- [SSI blog](https://software.ac.uk/using-continuous-integration-build-and-test-your-software?_ga=2.231776223.1391442519.1547641475-1644026160.1541158284) **Creative Commons Attribution Non-Commercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:423 +# unordered list +msgid "- [The difference between continuous integration, continuous deployment, and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:424 +# unordered list +msgid "- [CI with python](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:426 +# header +msgid "### Materials used: What is Travis and how does it work?" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:428 +# unordered list +msgid "- [Info about how Travis works](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/for-beginners.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:430 +# header +msgid "### Materials used: Setting up continuous integration with Travis" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:432 +# unordered list +msgid "- [Light travis tutorial](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/tutorial.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:433 +# unordered list +msgid "- [CI with travis](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:434 +# unordered list +msgid "- [Installing dependencies via yaml](https://github.com/travis-ci/docs-travis-ci-com/edit/master/user/installing-dependencies.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:435 +# unordered list +msgid "- [Testing multiple versions of programming languages](https://docs.python-guide.org/scenarios/ci/) **Attribution-NonCommercial-ShareAlike 3.0 Unported (CC BY-NC-SA 3.0)**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:436 +# unordered list +msgid "- [Using Travis with multiple operating systems](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/multi-os.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:437 +# unordered list +msgid "- [Travis docs: customising the build](https://docs.travis-ci.com/user/customizing-the-build/) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:439 +# header +msgid "### Materials used: Limitations of CI" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:441 +# unordered list +msgid "- [Security with Travis](https://github.com/travis-ci/docs-travis-ci-com/blob/master/user/best-practices-security.md) **MIT**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:443 +# header +msgid "### Materials used: Best practise for continuous integration" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:445 +# unordered list +msgid "- [Continuous integration, continuous deployment and continuous delivery](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:446 +# unordered list +msgid "- [Netherlands eScience Center guide](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International**" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:448 +# header +msgid "## Acknowledgements" +msgstr "" + +#: locale/zh_CN/continuous_integration/continuous_integration.md:450 +msgid "Thanks to David Jones of the University of Sheffield RSE group for useful discussions." +msgstr "" + +#: locale/zh_CN/credit/credit.md:1 +# header +msgid "# Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:3 +#: locale/zh_CN/credit/credit.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:13 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:14 +msgid "| ------------- | ---------- | ------ |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:15 +msgid "| [Reproducibility][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:16 +msgid "| [Open research][] | Useful but not essential | |" +msgstr "" + +#: locale/zh_CN/credit/credit.md:18 +msgid "[Reproducibility]: /reproducibility/reproducibility.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:19 +msgid "[Open research]: /open_research/open_research.html" +msgstr "" + +#: locale/zh_CN/credit/credit.md:21 +#: locale/zh_CN/open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:22 +# ordered list +msgid "2. [How this will help you/why this is useful?](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:23 +# ordered list +msgid "3. [Making it easy to cite your stuff](#making-it-easy-to-cite-your-stuff)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:24 +# ordered list +msgid "4. [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:25 +# ordered list +msgid "5. [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:26 +# ordered list +msgid "6. [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:30 +msgid "Reproducible research is great, but spending time on it will reduce the time you have available for activities by which researchers are traditionally measured, such as writing papers. But what if you could get credit for your reproducibility efforts as well?" +msgstr "" + +#: locale/zh_CN/credit/credit.md:34 +msgid "Academic research is a reputation economy, and citations are the currency. Most research institutions' promotion and hiring criteria depend to a greater or lesser extent on your publishing record: how many articles you have published, how \"important\" the journals were, and how many times each article has been cited." +msgstr "" + +#: locale/zh_CN/credit/credit.md:36 +msgid "This is a well established practice, and while it has its problems at least all stakeholders understand what's involved. One of the consequences of this system is that labour which *doesn't* result in published articles tends to be ignored, discouraging researchers from making their data more open or specialising in software development." +msgstr "" + +#: locale/zh_CN/credit/credit.md:38 +msgid "Establishing good citation practice for non-article content is a step towards recognising this valuable work and encouraging more people to take it up. If you can demonstrate the impact of your reproducible research work in addition to more traditional research outputs, you can justify spending more time on doing things right." +msgstr "" + +#: locale/zh_CN/credit/credit.md:40 +# header +msgid "## Making it easy to cite your stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:42 +msgid "There are many reasons why authors don't cite the data and software that they use, but one of the biggest ones is that it's not clear how. You can go a long way to reducing this barrier by following a few steps to make it as easy as possible." +msgstr "" + +#: locale/zh_CN/credit/credit.md:44 +# header +msgid "### Open research" +msgstr "" + +#: locale/zh_CN/credit/credit.md:46 +msgid "The first step is to ensure that you have something worth citing. Practising open research isn't essential to get credit for your data or software, but it makes it much easier for others to build on your work in a way that acknowledges your contribution. There is a growing body of evidence that shows open research tends to be cited more than non-open research of equivalent quality and significance." +msgstr "" + +#: locale/zh_CN/credit/credit.md:48 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:50 +# unordered list +msgid "* [Learn more about making your research open][open research]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:52 +# header +msgid "### Show people how to do it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:54 +msgid "Showing an example reference in the most common referencing format in your discipline serves two purposes:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:56 +# ordered list +msgid "1. It demonstrates that software & data are actually things that can be cited;" +msgstr "" + +#: locale/zh_CN/credit/credit.md:57 +# ordered list +msgid "2. It gives authors a reference that they can copy and paste directly into their document." +msgstr "" + +#: locale/zh_CN/credit/credit.md:59 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:60 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:62 +msgid "If you use GitHub, GitLab or similar, consider creating a `CITATION` file in each repository containing an example reference." +msgstr "" + +#: locale/zh_CN/credit/credit.md:64 +# header +msgid "### Add machine-readable referencing information" +msgstr "" + +#: locale/zh_CN/credit/credit.md:66 +msgid "You can go one better by allowing people to import information about your research objects into their preferred referencing database." +msgstr "" + +#: locale/zh_CN/credit/credit.md:67 +msgid "If BibTeX is popular in your field, post a `.bib` file of *all* your outputs, not just your papers; if it's Endnote, make an Endnote export available." +msgstr "" + +#: locale/zh_CN/credit/credit.md:68 +msgid "If possible, provide several formats: you won't need to update these very often and it will pay off." +msgstr "" + +#: locale/zh_CN/credit/credit.md:70 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:72 +# header +msgid "### Publish in software & data journals" +msgstr "" + +#: locale/zh_CN/credit/credit.md:74 +msgid "It's perfectly possible to cite a dataset or software package directly, and most major publishers now permit this in their style guides. However, it can sometimes help to have a more conventional paper to cite, and this is where software and data journals come in. These journals are similar to methods journals, in that they tend not to include significant results but instead focus on describing data and software in sufficient detail to allow reuse. Some examples include:" +msgstr "" + +#: locale/zh_CN/credit/credit.md:76 +# unordered list +msgid "- [Journal of Open Research Software][jors]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:77 +# unordered list +msgid "- [Journal of Open Source Software][joss]" +msgstr "" + +#: locale/zh_CN/credit/credit.md:79 +msgid "[JORS]: https://openresearchsoftware.metajnl.com/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:80 +msgid "[JOSS]: https://joss.theoj.org/" +msgstr "" + +#: locale/zh_CN/credit/credit.md:82 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:84 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:87 +# unordered list +msgid "- Making stuff citable" +msgstr "" + +#: locale/zh_CN/credit/credit.md:88 +# unordered list +msgid " - *Can this just link to other chapters mainly?*" +msgstr "" + +#: locale/zh_CN/credit/credit.md:89 +# unordered list +msgid " - Data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:90 +# unordered list +msgid " - Deposit it" +msgstr "" + +#: locale/zh_CN/credit/credit.md:91 +# unordered list +msgid " - Software" +msgstr "" + +#: locale/zh_CN/credit/credit.md:92 +# unordered list +msgid " - Deposit it (github isn't good enough)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:93 +# unordered list +msgid " - Software journals (such as [JORS][] and [JOSS][])" +msgstr "" + +#: locale/zh_CN/credit/credit.md:94 +# unordered list +msgid "- Citing stuff" +msgstr "" + +#: locale/zh_CN/credit/credit.md:95 +# unordered list +msgid " - Importance of using true citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:96 +# unordered list +msgid " - Different ways of citing" +msgstr "" + +#: locale/zh_CN/credit/credit.md:97 +# unordered list +msgid " - The data/software itself (preferred)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:98 +# unordered list +msgid " - A data/software paper from a dedicated data/software journal" +msgstr "" + +#: locale/zh_CN/credit/credit.md:99 +# unordered list +msgid " - A key paper identified by the creator/developer" +msgstr "" + +#: locale/zh_CN/credit/credit.md:100 +# unordered list +msgid " - A software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:101 +# unordered list +msgid " - What does/doesn't need to be cited" +msgstr "" + +#: locale/zh_CN/credit/credit.md:102 +# unordered list +msgid " - Overflow space for citations" +msgstr "" + +#: locale/zh_CN/credit/credit.md:107 +# header +msgid "### For authors" +msgstr "" + +#: locale/zh_CN/credit/credit.md:109 +# unordered list +msgid "- Pick out key datasets and software your conclusions rely on" +msgstr "" + +#: locale/zh_CN/credit/credit.md:110 +# unordered list +msgid "- Cite data and software just like you would cite a paper" +msgstr "" + +#: locale/zh_CN/credit/credit.md:111 +# unordered list +msgid "- Publish your own data/software and cite that too!" +msgstr "" + +#: locale/zh_CN/credit/credit.md:113 +# header +msgid "### For data creators" +msgstr "" + +#: locale/zh_CN/credit/credit.md:115 +# unordered list +msgid "- Deposit your data in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:116 +# unordered list +msgid "- Get a persistent identifier (DOI) for your data" +msgstr "" + +#: locale/zh_CN/credit/credit.md:117 +# unordered list +msgid "- Include an example citation in your dataset's README file" +msgstr "" + +#: locale/zh_CN/credit/credit.md:119 +# header +msgid "### For software developers" +msgstr "" + +#: locale/zh_CN/credit/credit.md:121 +# unordered list +msgid "- Deposit key version snapshots of your software in a stable repository" +msgstr "" + +#: locale/zh_CN/credit/credit.md:122 +# unordered list +msgid "- Get a distinct persistent identifier for each key version" +msgstr "" + +#: locale/zh_CN/credit/credit.md:123 +# unordered list +msgid "- Include an example citation in your software manual" +msgstr "" + +#: locale/zh_CN/credit/credit.md:125 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:129 +# unordered list +msgid "- [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:130 +# unordered list +msgid "- [FORCE11 Software Citation principles](https://www.force11.org/software-citation-principles)" +msgstr "" + +#: locale/zh_CN/credit/credit.md:132 +msgid "" +msgstr "" + +#: locale/zh_CN/credit/credit.md:134 +msgid "" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:1 +# header +msgid "### This is a list of figures in the book" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:3 +msgid "**To be kept in alphabetical order**" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:5 +msgid "| Filename | Chapter | Description |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:6 +msgid "| -------------------------- | ------------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:7 +msgid "| binder_comic | Reproducible environments | Cartoon showing using binder to share research |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:8 +msgid "| binder_home | Reproducible environments | Home screen of an example binder |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:9 +msgid "| binder_notebook | Reproducible environments | Interacting with an example binder via a notebook |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:10 +msgid "| binder_terminal | Reproducible environments | Interacting with an example binder via a terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:11 +msgid "| cd_example | Reproducible environments | Example of result of using cd in a Dockerfile |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:12 +msgid "| change_stage_repo | Version control | Cartoon showing staging and committing changes |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:13 +msgid "| container_example | Reproducible environments | Demo of a simple container in terminal |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:14 +msgid "| docker_official_image | Reproducible environments | The official ubuntu docker image with badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:15 +msgid "| eyeball_test_1 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:16 +msgid "| eyeball_test_2 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:17 +msgid "| eyeball_test_3 | Testing | Results tested by seeing if they 'look right' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:18 +msgid "| eyeball_test_error | Testing | Bug detected by result 'looking wrong' |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:19 +msgid "| flipped_taj_mahal | Version control | Upside down taj mahal to confuse people |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:20 +msgid "| master_branch | Version control | Illustrates commits on master branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:21 +msgid "| mybinder_gen_link | Reproducible environments | What the page to generate binder links looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:22 +msgid "| one_branch | Version control | Illustrates version control master + one branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:23 +msgid "| open_access_citatations | Open research | Impact of openness on citation count |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:24 +msgid "| open_umbrella | Open research | Terms under the umbrella of open scholarship |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:25 +msgid "| regents_map | BinderHub workshop | Map to workshop location |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:26 +msgid "| reproducibility_kirstie | | Depicts cow code and data relate to good practise |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:27 +msgid "| sub_branch | Version control | Illustrates version control branch + sub branch |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:28 +msgid "| testing_motivation_1 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:29 +msgid "| testing_motivation_2 | Testing | Example of consequence of not testing code |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:30 +msgid "| Travis_badge_fail | Continuous integration | A readme with a failing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:31 +msgid "| Travis_badge_pass | Continuous integration | A readme with a passing Travis badge |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:32 +msgid "| Travis_build | Continuous integration | What the Travis dashboard looks like |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:33 +msgid "| two_branches | Version control | Illustrates version control master + two branches |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:34 +msgid "| virtual_machine | Reproducible environments | Example of a virtual ubuntu machine on windows |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:35 +msgid "| VM_create_machine | Reproducible environments | How to create a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:36 +msgid "| VM_export_machine | Reproducible environments | How to export a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:37 +msgid "| VM_start_machine | Reproducible environments | How to start a virtual machine in virtualbox |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:38 +msgid "| workdir_example | Reproducible environments | Example of using workdir in Dockerfiles |" +msgstr "" + +#: locale/zh_CN/figures/figure_list.md:39 +msgid "| wtf_per_min.jpg | Version control | Good quality code = few wtf per min |" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:1 +# header +msgid "# Glossary" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:3 +# header +msgid "#### Binder" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:5 +msgid "A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:7 +# header +msgid "#### Computational environment" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:9 +msgid "Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:11 +# header +msgid "#### Conda" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:13 +msgid "A commonly used package management system." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:15 +# header +msgid "#### Container" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:17 +msgid "Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:19 +# header +msgid "#### Dockerfile" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:21 +msgid "A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:23 +# header +msgid "#### Image" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:25 +msgid "Files used for generating containers." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:27 +# header +msgid "#### Package management system" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:29 +msgid "A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:31 +# header +msgid "#### Virtual machine" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:33 +msgid "A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:35 +# header +msgid "#### YAML" +msgstr "" + +#: locale/zh_CN/glossary/glossary.md:37 +msgid "A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:1 +# header +msgid "# Welcome to the Turing Way" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:3 +msgid "_The Turing Way_ is a lightly opinionated guide to reproducible data science." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:5 +msgid "Our goal is to provide all the information that researchers need at the start of their projects to ensure that they are easy to reproduce at the end." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:7 +msgid "This also means making sure PhD students, postdocs, PIs, and funding teams know which parts of the \"responsibility of reproducibility\" they can affect, and what they should do to nudge data science to being more efficient, effective, and understandable." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:9 +msgid "![Cartoon of multiple people tending a garden - caption \"our community\"](../figures/community.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:11 +msgid "The book is collaboratively written and open from the start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:12 +msgid "If you would like to contribute please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch) or visit our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) to learn how to start." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:14 +msgid "We value the participation of every member of our community and want to ensure that every contributor has an enjoyable and fulfilling experience." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:15 +msgid "Accordingly, everyone who participates in the _Turing Way_ project is expected to show respect and courtesy to other community members at all times." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:16 +msgid "All contributions must abide by our [code of conduct](https://github.com/alan-turing-institute/the-turing-way/blob/master/CODE_OF_CONDUCT.md)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:18 +# header +msgid "## A little more background" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:20 +msgid "Reproducible research is necessary to ensure that scientific work can be trusted." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:21 +msgid "Funders and publishers are beginning to require that publications include access to the underlying data and the analysis code." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:22 +msgid "The goal is to ensure that all results can be independently verified and built upon in future work." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:23 +msgid "This is sometimes easier said than done." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:24 +msgid "Sharing these research outputs means understanding data management, library sciences, sofware development, and continuous integration techniques: skills that are not widely taught or expected of academic researchers and data scientists." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:26 +msgid "The Turing Way is a handbook to support students, their supervisors, funders, and journal editors in ensuring that reproducible data science is \"too easy not to do\"." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:27 +msgid "It will include training material on version control, analysis testing, open and transparent communication with future users, and build on Turing Institute case studies and workshops." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:28 +msgid "This project is openly developed and any and all questions, comments and recommendations are welcome at our GitHub repository: [https://github.com/alan-turing-institute/the-turing-way](https://github.com/alan-turing-institute/the-turing-way)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:30 +# header +msgid "## The book itself" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:32 +msgid "The book that you are reading is a [jupyter book](https://github.com/jupyter/jupyter-book/)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:33 +msgid "Jupyter books render markdown documents and jupyter notebooks as static html web pages." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:34 +msgid "They are easy to read and navigate...but also easy to edit and extend!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:35 +msgid "There are some great example books at [https://jupyterbook.org](https://jupyterbook.org)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:37 +msgid "Check out our [contributing guidelines](https://github.com/alan-turing-institute/the-turing-way/blob/master/CONTRIBUTING.md) on how you can help us build the most useful book we can!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:39 +# header +msgid "## The Turing Way Community" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:41 +msgid "_The Turing Way_ is built by an incredible team.....and you!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:43 +msgid "![](../figures/TuringWayTeam.jpg)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:45 +msgid "The lead investigator for this project is [Dr Kirstie Whitaker](https://whitakerlab.github.io/about)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:46 +msgid "She is a research fellow at the [Alan Turing Institute](http://turing.ac.uk) and senior research associate in the [Department of Psychiatry](https://www.psychiatry.cam.ac.uk) at the University of Cambridge." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:48 +msgid "Our core contributors are, in alphabetical order:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:50 +# unordered list +msgid "* [Rachael Ainsworth](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rachael-ainsworth)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:51 +# unordered list +msgid "* [Becky Arnold](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#becky-arnold)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:52 +# unordered list +msgid "* [Louise Bowler](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#louise-bowler)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:53 +# unordered list +msgid "* [Sarah Gibson](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#sarah-gibson)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:54 +# unordered list +msgid "* [Patricia Herterich](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#patricia-herterich)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:55 +# unordered list +msgid "* [Rosie Higman](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#rosie-higman)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:56 +# unordered list +msgid "* [Anna Krystalli](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#anna-krystalli)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:57 +# unordered list +msgid "* [Alexander Morley](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#alexander-morley)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:58 +# unordered list +msgid "* [Martin O'Reilly](https://github.com/alan-turing-institute/the-turing-way/blob/master/contributors.md#martin-oreilly)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:60 +msgid "You can see all of our incredible contributors in our [README](https://github.com/alan-turing-institute/the-turing-way#contributors) file, and screengrabbed below." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:62 +msgid "![Grid of pictures and names of project contributors](../figures/contributors-twopanel.png)" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:64 +# header +msgid "## Citing _The Turing Way_" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:66 +msgid "You can reference _The Turing Way_ through the project's Zenodo archive using doi: [10.5281/zenodo.3233853](https://doi.org/10.5281/zenodo.3233853)." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:68 +msgid "The citation will look something like:" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:70 +# blockquote, which can be cascaded +msgid "> The Turing Way Community, Becky Arnold, Louise Bowler, Sarah Gibson, Patricia Herterich, Rosie Higman, … Kirstie Whitaker. (2019, March 25). The Turing Way: A Handbook for Reproducible Data Science (Version v0.0.4). Zenodo. http://doi.org/10.5281/zenodo.3233986" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:72 +msgid "Please visit the [DOI link](https://doi.org/10.5281/zenodo.3233853) though to get the most recent version - the one above is not automatically generated and therefore may be out of date." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:73 +msgid "DOIs allow us to archive the repository and they are really valuable to ensure that the work is tracked in academic publications." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:75 +msgid "You can also share the human-readable URL to a page in the book, for example: [https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://the-turing-way.netlify.com/reproducibility/03/definitions.html), but be aware that the project is under development and therefore these links may change over time." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:76 +msgid "You might want to include a [web archive link](http://web.archive.org) such as: [https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html](https://web.archive.org/web/20191030093753/https://the-turing-way.netlify.com/reproducibility/03/definitions.html) to make sure that you don't end up with broken links everywhere!" +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:78 +msgid "We really appreciate any references that you make to _The Turing Way_ project in your and we hope it is useful." +msgstr "" + +#: locale/zh_CN/introduction/introduction.md:79 +msgid "If you have any questions please [get in touch](https://github.com/alan-turing-institute/the-turing-way#get-in-touch)." +msgstr "" + +#: locale/zh_CN/make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: locale/zh_CN/make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: locale/zh_CN/make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: locale/zh_CN/make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: locale/zh_CN/make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: locale/zh_CN/make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: locale/zh_CN/make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: locale/zh_CN/make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: locale/zh_CN/make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: locale/zh_CN/make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: locale/zh_CN/make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: locale/zh_CN/make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: locale/zh_CN/make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: locale/zh_CN/make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: locale/zh_CN/make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: locale/zh_CN/make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: locale/zh_CN/make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: locale/zh_CN/make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: locale/zh_CN/make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: locale/zh_CN/make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: locale/zh_CN/make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: locale/zh_CN/make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: locale/zh_CN/make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: locale/zh_CN/make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: locale/zh_CN/make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: locale/zh_CN/make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: locale/zh_CN/make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: locale/zh_CN/make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:54 +msgid "A " +msgstr "" + +#: locale/zh_CN/make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: locale/zh_CN/make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: locale/zh_CN/make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: locale/zh_CN/make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: locale/zh_CN/make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: locale/zh_CN/make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: locale/zh_CN/make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: locale/zh_CN/make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: locale/zh_CN/make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: locale/zh_CN/make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: locale/zh_CN/make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: locale/zh_CN/make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: locale/zh_CN/make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: locale/zh_CN/make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: locale/zh_CN/make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: locale/zh_CN/make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: locale/zh_CN/make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: locale/zh_CN/make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: locale/zh_CN/make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: locale/zh_CN/make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: locale/zh_CN/make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: locale/zh_CN/make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: locale/zh_CN/make/make.md:86 +msgid " control." +msgstr "" + +#: locale/zh_CN/make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: locale/zh_CN/make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: locale/zh_CN/make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: locale/zh_CN/make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: locale/zh_CN/make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: locale/zh_CN/make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: locale/zh_CN/make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: locale/zh_CN/make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: locale/zh_CN/make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: locale/zh_CN/make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: locale/zh_CN/make/make.md:100 +#: locale/zh_CN/make/make.md:250 +msgid "follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: locale/zh_CN/make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: locale/zh_CN/make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: locale/zh_CN/make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: locale/zh_CN/make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: locale/zh_CN/make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: locale/zh_CN/make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: locale/zh_CN/make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: locale/zh_CN/make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: locale/zh_CN/make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: locale/zh_CN/make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: locale/zh_CN/make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: locale/zh_CN/make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: locale/zh_CN/make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: locale/zh_CN/make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: locale/zh_CN/make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: locale/zh_CN/make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: locale/zh_CN/make/make.md:145 +msgid "**report**." +msgstr "" + +#: locale/zh_CN/make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: locale/zh_CN/make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: locale/zh_CN/make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: locale/zh_CN/make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: locale/zh_CN/make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: locale/zh_CN/make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: locale/zh_CN/make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: locale/zh_CN/make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: locale/zh_CN/make/make.md:168 +msgid "following contents:" +msgstr "" + +#: locale/zh_CN/make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: locale/zh_CN/make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: locale/zh_CN/make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: locale/zh_CN/make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: locale/zh_CN/make/make.md:192 +msgid "will be built." +msgstr "" + +#: locale/zh_CN/make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: locale/zh_CN/make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: locale/zh_CN/make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: locale/zh_CN/make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: locale/zh_CN/make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: locale/zh_CN/make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: locale/zh_CN/make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: locale/zh_CN/make/make.md:201 +msgid "change." +msgstr "" + +#: locale/zh_CN/make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: locale/zh_CN/make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: locale/zh_CN/make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: locale/zh_CN/make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: locale/zh_CN/make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: locale/zh_CN/make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: locale/zh_CN/make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: locale/zh_CN/make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: locale/zh_CN/make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: locale/zh_CN/make/make.md:213 +msgid "the following:" +msgstr "" + +#: locale/zh_CN/make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: locale/zh_CN/make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: locale/zh_CN/make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: locale/zh_CN/make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: locale/zh_CN/make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: locale/zh_CN/make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: locale/zh_CN/make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: locale/zh_CN/make/make.md:232 +msgid "The " +msgstr "" + +#: locale/zh_CN/make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: locale/zh_CN/make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: locale/zh_CN/make/make.md:235 +msgid "top!" +msgstr "" + +#: locale/zh_CN/make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: locale/zh_CN/make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: locale/zh_CN/make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: locale/zh_CN/make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: locale/zh_CN/make/make.md:244 +msgid " make the report." +msgstr "" + +#: locale/zh_CN/make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: locale/zh_CN/make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: locale/zh_CN/make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: locale/zh_CN/make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: locale/zh_CN/make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: locale/zh_CN/make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: locale/zh_CN/make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: locale/zh_CN/make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: locale/zh_CN/make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: locale/zh_CN/make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: locale/zh_CN/make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: locale/zh_CN/make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: locale/zh_CN/make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: locale/zh_CN/make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: locale/zh_CN/make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: locale/zh_CN/make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: locale/zh_CN/make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: locale/zh_CN/make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: locale/zh_CN/make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: locale/zh_CN/make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: locale/zh_CN/make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: locale/zh_CN/make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: locale/zh_CN/make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: locale/zh_CN/make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: locale/zh_CN/make/make.md:302 +msgid "targets:" +msgstr "" + +#: locale/zh_CN/make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: locale/zh_CN/make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: locale/zh_CN/make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: locale/zh_CN/make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: locale/zh_CN/make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: locale/zh_CN/make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: locale/zh_CN/make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: locale/zh_CN/make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: locale/zh_CN/make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: locale/zh_CN/make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: locale/zh_CN/make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: locale/zh_CN/make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: locale/zh_CN/make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: locale/zh_CN/make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: locale/zh_CN/make/make.md:345 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: locale/zh_CN/make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: locale/zh_CN/make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: locale/zh_CN/make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: locale/zh_CN/make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: locale/zh_CN/make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: locale/zh_CN/make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: locale/zh_CN/make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: locale/zh_CN/make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: locale/zh_CN/make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: locale/zh_CN/make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:382 +msgid "" +msgstr "" + +#: locale/zh_CN/make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: locale/zh_CN/make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: locale/zh_CN/make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: locale/zh_CN/make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: locale/zh_CN/make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: locale/zh_CN/make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: locale/zh_CN/make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: locale/zh_CN/make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: locale/zh_CN/make/make.md:413 +msgid "report!" +msgstr "" + +#: locale/zh_CN/make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: locale/zh_CN/make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: locale/zh_CN/make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: locale/zh_CN/make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: locale/zh_CN/make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: locale/zh_CN/make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: locale/zh_CN/make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: locale/zh_CN/make/make.md:425 +msgid "branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: locale/zh_CN/make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: locale/zh_CN/make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:454 +msgid "figures." +msgstr "" + +#: locale/zh_CN/make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: locale/zh_CN/make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: locale/zh_CN/make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: locale/zh_CN/make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: locale/zh_CN/make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: locale/zh_CN/make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: locale/zh_CN/make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: locale/zh_CN/make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: locale/zh_CN/make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: locale/zh_CN/make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: locale/zh_CN/make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: locale/zh_CN/make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: locale/zh_CN/make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: locale/zh_CN/make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: locale/zh_CN/make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: locale/zh_CN/make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: locale/zh_CN/make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: locale/zh_CN/make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: locale/zh_CN/make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: locale/zh_CN/make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: locale/zh_CN/make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: locale/zh_CN/make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: locale/zh_CN/make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: locale/zh_CN/make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: locale/zh_CN/make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: locale/zh_CN/make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: locale/zh_CN/make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: locale/zh_CN/make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: locale/zh_CN/make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: locale/zh_CN/make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: locale/zh_CN/make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: locale/zh_CN/make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: locale/zh_CN/make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: locale/zh_CN/make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: locale/zh_CN/make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: locale/zh_CN/make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: locale/zh_CN/make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: locale/zh_CN/make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: locale/zh_CN/make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: locale/zh_CN/make/make.md:567 +#: locale/zh_CN/make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: locale/zh_CN/make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: locale/zh_CN/make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: locale/zh_CN/make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: locale/zh_CN/make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: locale/zh_CN/make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: locale/zh_CN/make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: locale/zh_CN/make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: locale/zh_CN/make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: locale/zh_CN/make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: locale/zh_CN/make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: locale/zh_CN/make/make.md:589 +msgid "you could add:" +msgstr "" + +#: locale/zh_CN/make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: locale/zh_CN/make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: locale/zh_CN/make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: locale/zh_CN/make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: locale/zh_CN/make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: locale/zh_CN/make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: locale/zh_CN/make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: locale/zh_CN/make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: locale/zh_CN/make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: locale/zh_CN/make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: locale/zh_CN/make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: locale/zh_CN/make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: locale/zh_CN/make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: locale/zh_CN/make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: locale/zh_CN/make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: locale/zh_CN/make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: locale/zh_CN/make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: locale/zh_CN/make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: locale/zh_CN/make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: locale/zh_CN/make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: locale/zh_CN/make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: locale/zh_CN/make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: locale/zh_CN/make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: locale/zh_CN/make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: locale/zh_CN/make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: locale/zh_CN/make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: locale/zh_CN/make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: locale/zh_CN/make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: locale/zh_CN/make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: locale/zh_CN/make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: locale/zh_CN/make/make.md:645 +msgid "repository: " +msgstr "" + +#: locale/zh_CN/make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: locale/zh_CN/make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: locale/zh_CN/make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: locale/zh_CN/make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: locale/zh_CN/make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: locale/zh_CN/make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: locale/zh_CN/make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: locale/zh_CN/make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: locale/zh_CN/make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: locale/zh_CN/make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: locale/zh_CN/make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: locale/zh_CN/make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: locale/zh_CN/make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: locale/zh_CN/make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: locale/zh_CN/make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: locale/zh_CN/make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: locale/zh_CN/make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: locale/zh_CN/make/make.md:674 +msgid " filenames." +msgstr "" + +#: locale/zh_CN/make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: locale/zh_CN/make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: locale/zh_CN/make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: locale/zh_CN/make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: locale/zh_CN/make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: locale/zh_CN/make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: locale/zh_CN/make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: locale/zh_CN/make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: locale/zh_CN/make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: locale/zh_CN/make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: locale/zh_CN/make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: locale/zh_CN/make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: locale/zh_CN/make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: locale/zh_CN/make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: locale/zh_CN/make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: locale/zh_CN/make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: locale/zh_CN/make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: locale/zh_CN/make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: locale/zh_CN/make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: locale/zh_CN/make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: locale/zh_CN/make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: locale/zh_CN/make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: locale/zh_CN/make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: locale/zh_CN/make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: locale/zh_CN/make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: locale/zh_CN/make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: locale/zh_CN/make/make.md:717 +msgid " complex builds." +msgstr "" + +#: locale/zh_CN/make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: locale/zh_CN/make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: locale/zh_CN/make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: locale/zh_CN/make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: locale/zh_CN/make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: locale/zh_CN/make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: locale/zh_CN/make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: locale/zh_CN/make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: locale/zh_CN/make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: locale/zh_CN/make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: locale/zh_CN/make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: locale/zh_CN/make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: locale/zh_CN/make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: locale/zh_CN/make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: locale/zh_CN/make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: locale/zh_CN/make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: locale/zh_CN/make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: locale/zh_CN/make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: locale/zh_CN/make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: locale/zh_CN/make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: locale/zh_CN/make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: locale/zh_CN/make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: locale/zh_CN/make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: locale/zh_CN/make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: locale/zh_CN/make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: locale/zh_CN/make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: locale/zh_CN/make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: locale/zh_CN/make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: locale/zh_CN/make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: locale/zh_CN/make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: locale/zh_CN/make/make.md:763 +msgid " build system." +msgstr "" + +#: locale/zh_CN/make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: locale/zh_CN/make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: locale/zh_CN/make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: locale/zh_CN/make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: locale/zh_CN/make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: locale/zh_CN/make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: locale/zh_CN/make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: locale/zh_CN/make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: locale/zh_CN/make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: locale/zh_CN/make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: locale/zh_CN/make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: locale/zh_CN/make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: locale/zh_CN/make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: locale/zh_CN/make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: locale/zh_CN/make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: locale/zh_CN/make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: locale/zh_CN/make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: locale/zh_CN/make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: locale/zh_CN/make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: locale/zh_CN/make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: locale/zh_CN/make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: locale/zh_CN/make/make.md:798 +msgid " direction" +msgstr "" + +#: locale/zh_CN/make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: locale/zh_CN/make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: locale/zh_CN/make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: locale/zh_CN/make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: locale/zh_CN/make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: locale/zh_CN/make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: locale/zh_CN/make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: locale/zh_CN/make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: locale/zh_CN/make/make.md:815 +msgid "do have Make." +msgstr "" + +#: locale/zh_CN/make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: locale/zh_CN/make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: locale/zh_CN/make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: locale/zh_CN/make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: locale/zh_CN/make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: locale/zh_CN/make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: locale/zh_CN/make/make.md:830 +msgid " Linux:" +msgstr "" + +#: locale/zh_CN/make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: locale/zh_CN/make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: locale/zh_CN/make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: locale/zh_CN/make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: locale/zh_CN/make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: locale/zh_CN/make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: locale/zh_CN/make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: locale/zh_CN/make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: locale/zh_CN/make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: locale/zh_CN/make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: locale/zh_CN/make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: locale/zh_CN/make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: locale/zh_CN/make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: locale/zh_CN/make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: locale/zh_CN/make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: locale/zh_CN/make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: locale/zh_CN/make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: locale/zh_CN/make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: locale/zh_CN/make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: locale/zh_CN/make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: locale/zh_CN/make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: locale/zh_CN/make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: locale/zh_CN/make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: locale/zh_CN/make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: locale/zh_CN/make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: locale/zh_CN/make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: locale/zh_CN/make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: locale/zh_CN/make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: locale/zh_CN/make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: locale/zh_CN/make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: locale/zh_CN/make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: locale/zh_CN/make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: locale/zh_CN/make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: locale/zh_CN/make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: locale/zh_CN/make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: locale/zh_CN/make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: locale/zh_CN/make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: locale/zh_CN/make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: locale/zh_CN/make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: locale/zh_CN/make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: locale/zh_CN/make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: locale/zh_CN/make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: locale/zh_CN/make/make.md:980 +msgid "variable." +msgstr "" + +#: locale/zh_CN/make/make.md:982 +msgid "To build all of this, run" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:44 +#: locale/zh_CN/rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:57 +#: locale/zh_CN/rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: locale/zh_CN/open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:79 +#: locale/zh_CN/version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:80 +#: locale/zh_CN/version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:84 +#: locale/zh_CN/version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:85 +#: locale/zh_CN/version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:86 +#: locale/zh_CN/version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: locale/zh_CN/open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: locale/zh_CN/open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: locale/zh_CN/open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: locale/zh_CN/open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: locale/zh_CN/open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:1 +#: locale/zh_CN/reviewing/04/checklists_bib.md:1 +#: locale/zh_CN/version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:13 +#: locale/zh_CN/open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: locale/zh_CN/open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:6 +#: locale/zh_CN/version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:91 +#: locale/zh_CN/reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: locale/zh_CN/open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:74 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:87 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:100 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:164 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:189 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:209 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:216 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:238 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:252 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:289 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:311 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:315 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:341 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:426 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:430 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:488 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:517 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:521 +msgid "" +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: locale/zh_CN/rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: locale/zh_CN/reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: locale/zh_CN/reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: locale/zh_CN/reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: locale/zh_CN/reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: locale/zh_CN/reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: locale/zh_CN/reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:14 +#: locale/zh_CN/reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:15 +#: locale/zh_CN/reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:17 +#: locale/zh_CN/reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: locale/zh_CN/reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: locale/zh_CN/reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:46 +#: locale/zh_CN/reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:105 +#: locale/zh_CN/testing/testing.md:57 +msgid "" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: locale/zh_CN/reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: locale/zh_CN/reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: locale/zh_CN/reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: locale/zh_CN/reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: locale/zh_CN/reviewing/04/checklists_bib.md:56 +#: locale/zh_CN/testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: locale/zh_CN/reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: locale/zh_CN/reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: locale/zh_CN/reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:1 +#: locale/zh_CN/risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:2 +#: locale/zh_CN/risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:5 +#: locale/zh_CN/risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:9 +#: locale/zh_CN/risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:11 +#: locale/zh_CN/risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:13 +#: locale/zh_CN/risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:15 +#: locale/zh_CN/risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:17 +#: locale/zh_CN/risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: locale/zh_CN/risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: locale/zh_CN/risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:4 +#: locale/zh_CN/risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:25 +#: locale/zh_CN/risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: locale/zh_CN/risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + +#: locale/zh_CN/testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: locale/zh_CN/testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: locale/zh_CN/testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: locale/zh_CN/testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: locale/zh_CN/testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: locale/zh_CN/testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:76 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: locale/zh_CN/testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: locale/zh_CN/testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: locale/zh_CN/testing/testing.md:85 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:90 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: locale/zh_CN/testing/testing.md:97 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: locale/zh_CN/testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:106 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: locale/zh_CN/testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: locale/zh_CN/testing/testing.md:111 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: locale/zh_CN/testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: locale/zh_CN/testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: locale/zh_CN/testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: locale/zh_CN/testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:122 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: locale/zh_CN/testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: locale/zh_CN/testing/testing.md:127 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: locale/zh_CN/testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: locale/zh_CN/testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: locale/zh_CN/testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: locale/zh_CN/testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: locale/zh_CN/testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: locale/zh_CN/testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: locale/zh_CN/testing/testing.md:139 +#: locale/zh_CN/testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: locale/zh_CN/testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: locale/zh_CN/testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: locale/zh_CN/testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: locale/zh_CN/testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: locale/zh_CN/testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: locale/zh_CN/testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: locale/zh_CN/testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:154 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: locale/zh_CN/testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: locale/zh_CN/testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: locale/zh_CN/testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: locale/zh_CN/testing/testing.md:165 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: locale/zh_CN/testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: locale/zh_CN/testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: locale/zh_CN/testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: locale/zh_CN/testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: locale/zh_CN/testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: locale/zh_CN/testing/testing.md:179 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: locale/zh_CN/testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:184 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: locale/zh_CN/testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: locale/zh_CN/testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: locale/zh_CN/testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: locale/zh_CN/testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: locale/zh_CN/testing/testing.md:239 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: locale/zh_CN/testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: locale/zh_CN/testing/testing.md:246 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: locale/zh_CN/testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:267 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: locale/zh_CN/testing/testing.md:270 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: locale/zh_CN/testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: locale/zh_CN/testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: locale/zh_CN/testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: locale/zh_CN/testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:297 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: locale/zh_CN/testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: locale/zh_CN/testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: locale/zh_CN/testing/testing.md:325 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: locale/zh_CN/testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:334 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: locale/zh_CN/testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: locale/zh_CN/testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: locale/zh_CN/testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: locale/zh_CN/testing/testing.md:353 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: locale/zh_CN/testing/testing.md:360 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: locale/zh_CN/testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: locale/zh_CN/testing/testing.md:369 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: locale/zh_CN/testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: locale/zh_CN/testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: locale/zh_CN/testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: locale/zh_CN/testing/testing.md:395 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: locale/zh_CN/testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: locale/zh_CN/testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: locale/zh_CN/testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:467 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: locale/zh_CN/testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: locale/zh_CN/testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: locale/zh_CN/testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:480 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: locale/zh_CN/testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: locale/zh_CN/testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: locale/zh_CN/testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: locale/zh_CN/testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: locale/zh_CN/testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: locale/zh_CN/testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: locale/zh_CN/testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: locale/zh_CN/testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: locale/zh_CN/testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:516 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: locale/zh_CN/testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: locale/zh_CN/testing/testing.md:523 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: locale/zh_CN/testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: locale/zh_CN/testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: locale/zh_CN/testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: locale/zh_CN/testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: locale/zh_CN/testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:537 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: locale/zh_CN/testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: locale/zh_CN/testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: locale/zh_CN/testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:550 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: locale/zh_CN/testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: locale/zh_CN/testing/testing.md:557 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: locale/zh_CN/testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: locale/zh_CN/testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: locale/zh_CN/testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: locale/zh_CN/testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: locale/zh_CN/testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: locale/zh_CN/testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: locale/zh_CN/testing/testing.md:574 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: locale/zh_CN/testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: locale/zh_CN/testing/testing.md:579 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: locale/zh_CN/testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: locale/zh_CN/testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: locale/zh_CN/testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: locale/zh_CN/testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: locale/zh_CN/testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:618 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: locale/zh_CN/testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: locale/zh_CN/testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: locale/zh_CN/testing/testing.md:632 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: locale/zh_CN/testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: locale/zh_CN/testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: locale/zh_CN/testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:643 +msgid "" +msgstr "" + +#: locale/zh_CN/testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: locale/zh_CN/testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: locale/zh_CN/testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: locale/zh_CN/testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: locale/zh_CN/testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: locale/zh_CN/testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: locale/zh_CN/testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: locale/zh_CN/testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: locale/zh_CN/testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: locale/zh_CN/testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: locale/zh_CN/testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: locale/zh_CN/testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: locale/zh_CN/testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: locale/zh_CN/testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: locale/zh_CN/testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: locale/zh_CN/testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: locale/zh_CN/testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: locale/zh_CN/testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: locale/zh_CN/testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: locale/zh_CN/testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: locale/zh_CN/testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: locale/zh_CN/testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: locale/zh_CN/testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: locale/zh_CN/testing/testing.md:705 +#: locale/zh_CN/testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: locale/zh_CN/testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: locale/zh_CN/testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:726 +#: locale/zh_CN/testing/testing.md:731 +#: locale/zh_CN/testing/testing.md:737 +#: locale/zh_CN/testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: locale/zh_CN/testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: locale/zh_CN/testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: locale/zh_CN/testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: locale/zh_CN/testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:93 +#: locale/zh_CN/version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:142 +#: locale/zh_CN/version_control/version_control.md:183 +#: locale/zh_CN/version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:150 +#: locale/zh_CN/version_control/version_control.md:235 +#: locale/zh_CN/version_control/version_control.md:301 +#: locale/zh_CN/version_control/version_control.md:343 +#: locale/zh_CN/version_control/version_control.md:406 +#: locale/zh_CN/version_control/version_control.md:447 +#: locale/zh_CN/version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:155 +#: locale/zh_CN/version_control/version_control.md:241 +#: locale/zh_CN/version_control/version_control.md:305 +#: locale/zh_CN/version_control/version_control.md:352 +#: locale/zh_CN/version_control/version_control.md:410 +#: locale/zh_CN/version_control/version_control.md:473 +#: locale/zh_CN/version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:160 +#: locale/zh_CN/version_control/version_control.md:251 +#: locale/zh_CN/version_control/version_control.md:313 +#: locale/zh_CN/version_control/version_control.md:370 +#: locale/zh_CN/version_control/version_control.md:415 +#: locale/zh_CN/version_control/version_control.md:493 +#: locale/zh_CN/version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:216 +#: locale/zh_CN/version_control/version_control.md:266 +#: locale/zh_CN/version_control/version_control.md:334 +#: locale/zh_CN/version_control/version_control.md:396 +#: locale/zh_CN/version_control/version_control.md:438 +#: locale/zh_CN/version_control/version_control.md:513 +#: locale/zh_CN/version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:578 +#: locale/zh_CN/version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: locale/zh_CN/version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/make.es.po b/book/content/po/make.es.po new file mode 100644 index 00000000000..65b1bd073b6 --- /dev/null +++ b/book/content/po/make.es.po @@ -0,0 +1,2465 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: make/make.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: make/make.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: make/make.md:12 +# header +msgid "## Table of contents" +msgstr "" + +#: make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: make/make.md:40 +# header +msgid "## Summary" +msgstr "" + +#: make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: make/make.md:54 +msgid "A " +msgstr "" + +#: make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: make/make.md:86 +msgid " control." +msgstr "" + +#: make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: make/make.md:100 +#: make/make.md:250 +msgid "follows:" +msgstr "" + +#: make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: make/make.md:145 +msgid "**report**." +msgstr "" + +#: make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: make/make.md:168 +msgid "following contents:" +msgstr "" + +#: make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: make/make.md:192 +msgid "will be built." +msgstr "" + +#: make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: make/make.md:201 +msgid "change." +msgstr "" + +#: make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: make/make.md:213 +msgid "the following:" +msgstr "" + +#: make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: make/make.md:232 +msgid "The " +msgstr "" + +#: make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: make/make.md:235 +msgid "top!" +msgstr "" + +#: make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: make/make.md:244 +msgid " make the report." +msgstr "" + +#: make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: make/make.md:302 +msgid "targets:" +msgstr "" + +#: make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: make/make.md:345 +msgid "" +msgstr "" + +#: make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: make/make.md:382 +msgid "" +msgstr "" + +#: make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: make/make.md:413 +msgid "report!" +msgstr "" + +#: make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: make/make.md:425 +msgid "branch:" +msgstr "" + +#: make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: make/make.md:454 +msgid "figures." +msgstr "" + +#: make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: make/make.md:567 +#: make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: make/make.md:589 +msgid "you could add:" +msgstr "" + +#: make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: make/make.md:645 +msgid "repository: " +msgstr "" + +#: make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: make/make.md:674 +msgid " filenames." +msgstr "" + +#: make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: make/make.md:717 +msgid " complex builds." +msgstr "" + +#: make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: make/make.md:763 +msgid " build system." +msgstr "" + +#: make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: make/make.md:798 +msgid " direction" +msgstr "" + +#: make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: make/make.md:815 +msgid "do have Make." +msgstr "" + +#: make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: make/make.md:830 +msgid " Linux:" +msgstr "" + +#: make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: make/make.md:980 +msgid "variable." +msgstr "" + +#: make/make.md:982 +msgid "To build all of this, run" +msgstr "" + diff --git a/book/content/po/make.pot b/book/content/po/make.pot new file mode 100644 index 00000000000..190b4a48df5 --- /dev/null +++ b/book/content/po/make.pot @@ -0,0 +1,2465 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: make/make.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: make/make.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: make/make.md:12 +# header +msgid "## Table of contents" +msgstr "" + +#: make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: make/make.md:40 +# header +msgid "## Summary" +msgstr "" + +#: make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: make/make.md:54 +msgid "A " +msgstr "" + +#: make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: make/make.md:86 +msgid " control." +msgstr "" + +#: make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: make/make.md:100 +#: make/make.md:250 +msgid "follows:" +msgstr "" + +#: make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: make/make.md:145 +msgid "**report**." +msgstr "" + +#: make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: make/make.md:168 +msgid "following contents:" +msgstr "" + +#: make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: make/make.md:192 +msgid "will be built." +msgstr "" + +#: make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: make/make.md:201 +msgid "change." +msgstr "" + +#: make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: make/make.md:213 +msgid "the following:" +msgstr "" + +#: make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: make/make.md:232 +msgid "The " +msgstr "" + +#: make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: make/make.md:235 +msgid "top!" +msgstr "" + +#: make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: make/make.md:244 +msgid " make the report." +msgstr "" + +#: make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: make/make.md:302 +msgid "targets:" +msgstr "" + +#: make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: make/make.md:345 +msgid "" +msgstr "" + +#: make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: make/make.md:382 +msgid "" +msgstr "" + +#: make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: make/make.md:413 +msgid "report!" +msgstr "" + +#: make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: make/make.md:425 +msgid "branch:" +msgstr "" + +#: make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: make/make.md:454 +msgid "figures." +msgstr "" + +#: make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: make/make.md:567 +#: make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: make/make.md:589 +msgid "you could add:" +msgstr "" + +#: make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: make/make.md:645 +msgid "repository: " +msgstr "" + +#: make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: make/make.md:674 +msgid " filenames." +msgstr "" + +#: make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: make/make.md:717 +msgid " complex builds." +msgstr "" + +#: make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: make/make.md:763 +msgid " build system." +msgstr "" + +#: make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: make/make.md:798 +msgid " direction" +msgstr "" + +#: make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: make/make.md:815 +msgid "do have Make." +msgstr "" + +#: make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: make/make.md:830 +msgid " Linux:" +msgstr "" + +#: make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: make/make.md:980 +msgid "variable." +msgstr "" + +#: make/make.md:982 +msgid "To build all of this, run" +msgstr "" + diff --git a/book/content/po/make.tr.po b/book/content/po/make.tr.po new file mode 100644 index 00000000000..190b4a48df5 --- /dev/null +++ b/book/content/po/make.tr.po @@ -0,0 +1,2465 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: make/make.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: make/make.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: make/make.md:12 +# header +msgid "## Table of contents" +msgstr "" + +#: make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: make/make.md:40 +# header +msgid "## Summary" +msgstr "" + +#: make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: make/make.md:54 +msgid "A " +msgstr "" + +#: make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: make/make.md:86 +msgid " control." +msgstr "" + +#: make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: make/make.md:100 +#: make/make.md:250 +msgid "follows:" +msgstr "" + +#: make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: make/make.md:145 +msgid "**report**." +msgstr "" + +#: make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: make/make.md:168 +msgid "following contents:" +msgstr "" + +#: make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: make/make.md:192 +msgid "will be built." +msgstr "" + +#: make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: make/make.md:201 +msgid "change." +msgstr "" + +#: make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: make/make.md:213 +msgid "the following:" +msgstr "" + +#: make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: make/make.md:232 +msgid "The " +msgstr "" + +#: make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: make/make.md:235 +msgid "top!" +msgstr "" + +#: make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: make/make.md:244 +msgid " make the report." +msgstr "" + +#: make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: make/make.md:302 +msgid "targets:" +msgstr "" + +#: make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: make/make.md:345 +msgid "" +msgstr "" + +#: make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: make/make.md:382 +msgid "" +msgstr "" + +#: make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: make/make.md:413 +msgid "report!" +msgstr "" + +#: make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: make/make.md:425 +msgid "branch:" +msgstr "" + +#: make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: make/make.md:454 +msgid "figures." +msgstr "" + +#: make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: make/make.md:567 +#: make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: make/make.md:589 +msgid "you could add:" +msgstr "" + +#: make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: make/make.md:645 +msgid "repository: " +msgstr "" + +#: make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: make/make.md:674 +msgid " filenames." +msgstr "" + +#: make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: make/make.md:717 +msgid " complex builds." +msgstr "" + +#: make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: make/make.md:763 +msgid " build system." +msgstr "" + +#: make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: make/make.md:798 +msgid " direction" +msgstr "" + +#: make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: make/make.md:815 +msgid "do have Make." +msgstr "" + +#: make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: make/make.md:830 +msgid " Linux:" +msgstr "" + +#: make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: make/make.md:980 +msgid "variable." +msgstr "" + +#: make/make.md:982 +msgid "To build all of this, run" +msgstr "" + diff --git a/book/content/po/make.zh_CN.po b/book/content/po/make.zh_CN.po new file mode 100644 index 00000000000..c4e20d0ec92 --- /dev/null +++ b/book/content/po/make.zh_CN.po @@ -0,0 +1,2466 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: make/make.md:1 +# header +msgid "# Reproducibility with Make" +msgstr "" + +#: make/make.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: make/make.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: make/make.md:6 +msgid "| ------------ | ---------- | ----- |" +msgstr "" + +#: make/make.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | |" +msgstr "" + +#: make/make.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git is useful to follow along with examples |" +msgstr "" + +#: make/make.md:10 +msgid "Recommended skill level: intermediate" +msgstr "" + +#: make/make.md:12 +# header +msgid "## Table of contents" +msgstr "" + +#: make/make.md:14 +# unordered list +msgid "- [Summary](#summary)" +msgstr "" + +#: make/make.md:15 +# unordered list +msgid "- [An Introduction to Make](#an-introduction-to-make)" +msgstr "" + +#: make/make.md:16 +# unordered list +msgid " - [What is Make](#what-is-make)" +msgstr "" + +#: make/make.md:17 +# unordered list +msgid " - [Why use Make for Reproducible Research?](#why-use-make-for-reproducible-research)" +msgstr "" + +#: make/make.md:18 +# unordered list +msgid "- [Learn Make by Example](#learn-make-by-example)" +msgstr "" + +#: make/make.md:19 +# unordered list +msgid " - [Setting up](#setting-up)" +msgstr "" + +#: make/make.md:20 +# unordered list +msgid " - [Makefile no. 1 (The Basics)](#makefile-no-1-the-basics)" +msgstr "" + +#: make/make.md:21 +# unordered list +msgid " - [Makefile no. 2 (all and clean)](#makefile-no-2-all-and-clean)" +msgstr "" + +#: make/make.md:22 +# unordered list +msgid " - [Makefile no. 3 (Phony Targets)](#makefile-no-3-phony-targets)" +msgstr "" + +#: make/make.md:23 +# unordered list +msgid " - [Makefile no. 4 (Automatic Variables and Pattern Rules)](#makefile-no-4-automatic-variables-and-pattern-rules)" +msgstr "" + +#: make/make.md:24 +# unordered list +msgid " - [Makefile no. 5 (Wildcards and Path Substitution)](#makefile-no-5-wildcards-and-path-substitution)" +msgstr "" + +#: make/make.md:25 +# unordered list +msgid " - [Debugging Makefiles](#debugging-makefiles)" +msgstr "" + +#: make/make.md:26 +# unordered list +msgid "- [A Real Reproducible Paper using Make](#a-real-reproducible-paper-using-make)" +msgstr "" + +#: make/make.md:27 +# unordered list +msgid "- [Further Reading](#further-reading)" +msgstr "" + +#: make/make.md:28 +# unordered list +msgid " - [Manual](#manual)" +msgstr "" + +#: make/make.md:29 +# unordered list +msgid " - [Discussions](#discussions)" +msgstr "" + +#: make/make.md:30 +# unordered list +msgid " - [Blogs](#blogs)" +msgstr "" + +#: make/make.md:31 +# unordered list +msgid " - [Tools](#tools)" +msgstr "" + +#: make/make.md:32 +# unordered list +msgid " - [Alternatives to Make](#alternatives-to-make)" +msgstr "" + +#: make/make.md:33 +# unordered list +msgid "- [Glossary](#glossary)" +msgstr "" + +#: make/make.md:34 +# unordered list +msgid "- [Appendix](#appendix)" +msgstr "" + +#: make/make.md:35 +# unordered list +msgid " - [Directed Acyclic Graph](#directed-acyclic-graph)" +msgstr "" + +#: make/make.md:36 +# unordered list +msgid " - [Installing Make](#installing-make)" +msgstr "" + +#: make/make.md:37 +# unordered list +msgid " - [Advanced: Generating Rules using Call](#advanced-generating-rules-using-call)" +msgstr "" + +#: make/make.md:40 +# header +msgid "## Summary" +msgstr "" + +#: make/make.md:42 +msgid "A data science or research project can be seen as a tree of dependencies: the " +msgstr "" + +#: make/make.md:43 +msgid "report depends on the figures and tables, and these in turn depend on the data " +msgstr "" + +#: make/make.md:44 +msgid "and the analysis scripts used to process this data (illustrated in the figure " +msgstr "" + +#: make/make.md:45 +msgid "below). Make is a tool for creating output files from their dependencies " +msgstr "" + +#: make/make.md:46 +msgid "through pre-specified rules. It is possible to combine these two ideas to " +msgstr "" + +#: make/make.md:47 +msgid "create a reproducible project with Make. In this chapter we give an " +msgstr "" + +#: make/make.md:48 +msgid "introduction to Make and provide a tutorial on how Make can be used for a data " +msgstr "" + +#: make/make.md:49 +msgid "analysis pipeline. We also describe a real-world reproducible research " +msgstr "" + +#: make/make.md:50 +msgid "project that uses Make to go from the raw input data to the experiments all " +msgstr "" + +#: make/make.md:51 +msgid "the way to the pdf file of the paper!" +msgstr "" + +#: make/make.md:53 +msgid "![Schematic of a research project](../figures/make/research_dag.png)" +msgstr "" + +#: make/make.md:54 +msgid "A " +msgstr "" + +#: make/make.md:55 +msgid "schematic for a research project that uses LaTeX." +msgstr "" + +#: make/make.md:57 +# header +msgid "## An Introduction to Make" +msgstr "" + +#: make/make.md:59 +# header +msgid "### What is Make" +msgstr "" + +#: make/make.md:61 +msgid "Make is a build automation tool. It uses a configuration file called a " +msgstr "" + +#: make/make.md:62 +msgid "Makefile that contains the *rules* for what to build. Make builds *targets* " +msgstr "" + +#: make/make.md:63 +msgid "using *recipes*. Targets can optionally have *prerequisites*. Prerequisites " +msgstr "" + +#: make/make.md:64 +msgid "can be files on your computer or other targets. Make determines what to build " +msgstr "" + +#: make/make.md:65 +msgid "based on the dependency tree of the targets and prerequisites (technically, " +msgstr "" + +#: make/make.md:66 +msgid "this is a [directed acyclic graph](#directed-acyclic-graph)). It uses the " +msgstr "" + +#: make/make.md:67 +msgid "*modification time* of prerequisites to update targets only when needed." +msgstr "" + +#: make/make.md:69 +# header +msgid "### Why use Make for Reproducibility?" +msgstr "" + +#: make/make.md:71 +msgid "There are several reasons why Make is a good tool to use for reproducibility:" +msgstr "" + +#: make/make.md:73 +# ordered list +msgid "1. Make is easy to learn" +msgstr "" + +#: make/make.md:74 +# ordered list +msgid "1. Make is available on many platforms" +msgstr "" + +#: make/make.md:75 +# ordered list +msgid "1. Many people are already familiar with Make" +msgstr "" + +#: make/make.md:76 +# ordered list +msgid "1. Makefiles reduce cognitive load because as long as the common Make targets " +msgstr "" + +#: make/make.md:77 +msgid " ``all`` and ``clean`` are present (explained below), you can be up and " +msgstr "" + +#: make/make.md:78 +msgid " running without having to read lengthy instructions. This is especially " +msgstr "" + +#: make/make.md:79 +msgid " useful when you work on someone else's project or on one that you haven't " +msgstr "" + +#: make/make.md:80 +msgid " used in a long time." +msgstr "" + +#: make/make.md:81 +# ordered list +msgid "1. Makefiles are human-readable and machine-readable text files. So instead of " +msgstr "" + +#: make/make.md:82 +msgid " writing instructions to a human for how to build a report or output, you " +msgstr "" + +#: make/make.md:83 +msgid " can provide a Makefile with instructions that can be read by a human *and* " +msgstr "" + +#: make/make.md:84 +msgid " executed by a computer." +msgstr "" + +#: make/make.md:85 +# ordered list +msgid "1. Because Makefiles are text files they are easy to share and keep in version " +msgstr "" + +#: make/make.md:86 +msgid " control." +msgstr "" + +#: make/make.md:87 +# ordered list +msgid "1. Using Make doesn't exclude using other tools such as Travis and Docker." +msgstr "" + +#: make/make.md:89 +# header +msgid "## Learn Make by Example" +msgstr "" + +#: make/make.md:91 +msgid "One of the things that might scare people off from using Make is that existing " +msgstr "" + +#: make/make.md:92 +msgid "Makefiles can seem daunting and it may seem difficult to tailor to your own " +msgstr "" + +#: make/make.md:93 +msgid "needs. In this hands-on tutorial we will iteratively construct a Makefile for " +msgstr "" + +#: make/make.md:94 +msgid "a real data analysis project. The idea is to explain different features of " +msgstr "" + +#: make/make.md:95 +msgid "Make by iterating through several versions of a Makefile for this project. " +msgstr "" + +#: make/make.md:96 +msgid "Hopefully the experience that you gain from this tutorial allows you to create " +msgstr "" + +#: make/make.md:97 +msgid "Makefiles for your own projects." +msgstr "" + +#: make/make.md:99 +msgid "We will create a ``Makefile`` for a data analysis pipeline. The task is as " +msgstr "" + +#: make/make.md:100 +#: make/make.md:250 +msgid "follows:" +msgstr "" + +#: make/make.md:102 +# blockquote, which can be cascaded +msgid "> **Task: Given some datasets, create a summary report (in pdf) that contains " +msgstr "" + +#: make/make.md:103 +# blockquote, which can be cascaded +msgid "> the histograms of these datasets.**" +msgstr "" + +#: make/make.md:105 +msgid "(Of course this data task is very simple to focus on how to use Make.)" +msgstr "" + +#: make/make.md:107 +msgid "*Throughout the tutorial code blocks that start with a dollar sign (``$``) are " +msgstr "" + +#: make/make.md:108 +msgid "intended to be typed in the terminal.*" +msgstr "" + +#: make/make.md:110 +# header +msgid "### Setting up" +msgstr "" + +#: make/make.md:112 +msgid "We have created a basic repository for this task, that already contains " +msgstr "" + +#: make/make.md:113 +msgid "everything that we need (*except the Makefile of course!*). To start, clone " +msgstr "" + +#: make/make.md:114 +msgid "the base repository using git:" +msgstr "" + +#: make/make.md:116 +# code block +msgid "```bash\n" +"$ git clone https://github.com/alan-turing-institute/IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:120 +msgid "This basic repository contains all the code that we'll need in this tutorial, " +msgstr "" + +#: make/make.md:121 +msgid "and should have this content:" +msgstr "" + +#: make/make.md:123 +# code block +msgid "```text\n" +".\n" +"├── data/\n" +"│ ├── input_file_1.csv\n" +"│ └── input_file_2.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:137 +# unordered list +msgid "- **data**: directory with two datasets that we're going to analyse" +msgstr "" + +#: make/make.md:138 +# unordered list +msgid "- **report**: the input directory for the report" +msgstr "" + +#: make/make.md:139 +# unordered list +msgid "- **scripts**: directory for the analysis script" +msgstr "" + +#: make/make.md:140 +# unordered list +msgid "- **output**: output directory for the figures and the report" +msgstr "" + +#: make/make.md:142 +msgid "You'll notice that there are two datasets in the **data** directory " +msgstr "" + +#: make/make.md:143 +msgid "(``input_file_1.csv`` and ``input_file_2.csv``) and that there is already a " +msgstr "" + +#: make/make.md:144 +msgid "basic Python script in **scripts** and a basic report LaTeX file in " +msgstr "" + +#: make/make.md:145 +msgid "**report**." +msgstr "" + +#: make/make.md:147 +msgid "If you want to follow along, ensure that you have the ``matplotlib`` and " +msgstr "" + +#: make/make.md:148 +msgid "``numpy`` packages installed:" +msgstr "" + +#: make/make.md:150 +# code block +msgid "```bash\n" +"$ pip install matplotlib numpy\n" +"```" +msgstr "" + +#: make/make.md:154 +msgid "You will also need a working version of ``pdflatex`` and, of course, ``make``. " +msgstr "" + +#: make/make.md:155 +msgid "For installation instructions for Make, see [the installation instructions " +msgstr "" + +#: make/make.md:156 +msgid "below](#installing-make)." +msgstr "" + +#: make/make.md:158 +# header +msgid "### Makefile no. 1 (The Basics)" +msgstr "" + +#: make/make.md:160 +msgid "Let's create our first Makefile. In the terminal, move into the " +msgstr "" + +#: make/make.md:161 +msgid "``IntroToMake`` repository that you just cloned:" +msgstr "" + +#: make/make.md:163 +# code block +msgid "```bash\n" +"$ cd IntroToMake\n" +"```" +msgstr "" + +#: make/make.md:167 +msgid "Using your favourite editor, create a file called ``Makefile`` with the " +msgstr "" + +#: make/make.md:168 +msgid "following contents:" +msgstr "" + +#: make/make.md:170 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:182 +msgid "The indentation in each of the recipes are ***tabs***, Makefiles do not accept " +msgstr "" + +#: make/make.md:183 +msgid "indentation with spaces." +msgstr "" + +#: make/make.md:185 +msgid "You should now be able to type:" +msgstr "" + +#: make/make.md:187 +# code block +msgid "```bash\n" +"$ make output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:191 +msgid "If everything worked correctly, the two figures will be created and pdf report " +msgstr "" + +#: make/make.md:192 +msgid "will be built." +msgstr "" + +#: make/make.md:194 +msgid "Let's go through the Makefile in a bit more detail. We have three rules, two " +msgstr "" + +#: make/make.md:195 +msgid "for the figures and one for the report. Let's look at the rule for " +msgstr "" + +#: make/make.md:196 +msgid "``output/figure_1.png`` first. This rule has the target " +msgstr "" + +#: make/make.md:197 +msgid "``output/figure_1.png`` that has two prerequisites: ``data/input_file_1.csv`` " +msgstr "" + +#: make/make.md:198 +msgid "and ``scripts/generate_histogram.py``. By giving the output file these " +msgstr "" + +#: make/make.md:199 +msgid "prerequisites it will be updated if either of these files changes. This is one " +msgstr "" + +#: make/make.md:200 +msgid "of the reasons why Make was created: to update output files when source files " +msgstr "" + +#: make/make.md:201 +msgid "change." +msgstr "" + +#: make/make.md:203 +msgid "You'll notice that the recipe line calls Python with the script name and uses " +msgstr "" + +#: make/make.md:204 +msgid "command line flags (``-i`` and ``-o``) to mark the input and output of the " +msgstr "" + +#: make/make.md:205 +msgid "script. This isn't a requirement for using Make, but it makes it easy to see " +msgstr "" + +#: make/make.md:206 +msgid "which file is an input to the script and which is an output." +msgstr "" + +#: make/make.md:208 +msgid "The rule for the PDF report is very similar, but it has three prerequisites " +msgstr "" + +#: make/make.md:209 +msgid "(the LaTeX source and both figures). Notice that the recipe changes the " +msgstr "" + +#: make/make.md:210 +msgid "working directory before calling LaTeX and also moves the generated PDF to the " +msgstr "" + +#: make/make.md:211 +msgid "output directory. We're doing this to keep the LaTeX intermediate files in the " +msgstr "" + +#: make/make.md:212 +msgid "report directory. However, it's important to distinguish the above rule from " +msgstr "" + +#: make/make.md:213 +msgid "the following:" +msgstr "" + +#: make/make.md:215 +# code block +msgid "```makefile\n" +"# don't do this\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/\n" +" pdflatex report.tex\n" +" mv report.pdf ../output/report.pdf\n" +"```" +msgstr "" + +#: make/make.md:223 +msgid "This rule places the three commands on separate lines. However, **Make " +msgstr "" + +#: make/make.md:224 +msgid "executes each line independently** in a separate subshell, so changing the " +msgstr "" + +#: make/make.md:225 +msgid "working directory in the first line has no effect on the second, and a failure " +msgstr "" + +#: make/make.md:226 +msgid "in the second line won't stop the third line from being executed. Therefore, " +msgstr "" + +#: make/make.md:227 +msgid "we combine the three commands in a single recipe above." +msgstr "" + +#: make/make.md:229 +msgid "This is what the dependency tree looks like for this Makefile:" +msgstr "" + +#: make/make.md:231 +msgid "![DAG for Makefile no. 1](../figures/make/makefile_no_1.png)" +msgstr "" + +#: make/make.md:232 +msgid "The " +msgstr "" + +#: make/make.md:233 +msgid "dependency graph for our first Makefile, created using " +msgstr "" + +#: make/make.md:234 +msgid "[makefile2graph](#tools). Notice the similarity to the figure at the " +msgstr "" + +#: make/make.md:235 +msgid "top!" +msgstr "" + +#: make/make.md:238 +# header +msgid "### Makefile no. 2 (all and clean)" +msgstr "" + +#: make/make.md:240 +msgid "In our first Makefile we have the basic rules in place. We could stick with " +msgstr "" + +#: make/make.md:241 +msgid "this if we wanted to, but there are a few improvements we can make:" +msgstr "" + +#: make/make.md:243 +# ordered list +msgid "1. We now have to explicitly call ``make output/report.pdf`` if we want to " +msgstr "" + +#: make/make.md:244 +msgid " make the report." +msgstr "" + +#: make/make.md:246 +# ordered list +msgid "2. We have no way to clean up and start fresh." +msgstr "" + +#: make/make.md:248 +msgid "Let's remedy this by adding two new targets: ``all`` and ``clean``. In your " +msgstr "" + +#: make/make.md:249 +msgid "editor, change the Makefile contents to add the ``all`` and ``clean`` rules as " +msgstr "" + +#: make/make.md:252 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.png\n" +"```" +msgstr "" + +#: make/make.md:271 +msgid "Note that we've added the ``all`` target to the top of the file. We do this " +msgstr "" + +#: make/make.md:272 +msgid "because Make executes the *first* target when no explicit target is given. So " +msgstr "" + +#: make/make.md:273 +msgid "you can now type ``make`` on the command line and it would do the same as " +msgstr "" + +#: make/make.md:274 +msgid "``make all``. Also, note that we've only added the report as the prerequisite " +msgstr "" + +#: make/make.md:275 +msgid "of ``all`` because that's our desired output and the other rules help to build " +msgstr "" + +#: make/make.md:276 +msgid "that output. If you have multiple outputs, you could add these as further " +msgstr "" + +#: make/make.md:277 +msgid "prerequisites to the ``all`` target. Calling the main target ``all`` is a " +msgstr "" + +#: make/make.md:278 +msgid "convention of Makefiles that many people follow." +msgstr "" + +#: make/make.md:280 +msgid "The ``clean`` rule is typically at the bottom, but that's more style than " +msgstr "" + +#: make/make.md:281 +msgid "requirement. Note that we use the ``-f`` flag to ``rm`` to make sure it " +msgstr "" + +#: make/make.md:282 +msgid "doesn't complain when there is no file to remove." +msgstr "" + +#: make/make.md:284 +msgid "You can try out the new Makefile by running:" +msgstr "" + +#: make/make.md:286 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:291 +msgid "Make should remove the output and intermediate files after the first command, " +msgstr "" + +#: make/make.md:292 +msgid "and generate them again after the second." +msgstr "" + +#: make/make.md:294 +# header +msgid "### Makefile no. 3 (Phony Targets)" +msgstr "" + +#: make/make.md:296 +msgid "Typically, ``all`` and ``clean`` are defined as so-called [Phony " +msgstr "" + +#: make/make.md:297 +msgid "Targets](https://www.gnu.org/software/make/manual/make.html#Phony-Targets). " +msgstr "" + +#: make/make.md:298 +msgid "These are targets that don't actually create an output file. Such targets will " +msgstr "" + +#: make/make.md:299 +msgid "always be run if they come up in a dependency, but will no longer be run if a " +msgstr "" + +#: make/make.md:300 +msgid "directory/file is ever created that is called ``all`` or ``clean``. We " +msgstr "" + +#: make/make.md:301 +msgid "therefore add a line at the top of the Makefile to define these two as phony " +msgstr "" + +#: make/make.md:302 +msgid "targets:" +msgstr "" + +#: make/make.md:304 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_1.csv -o output/figure_1.png\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i data/input_file_2.csv -o output/figure_2.png\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:325 +msgid "Phony targets are also useful when you want to use Make recursively. In that " +msgstr "" + +#: make/make.md:326 +msgid "case you would specify the subdirectories as phony targets. You can read more " +msgstr "" + +#: make/make.md:327 +msgid "about [phony targets in the " +msgstr "" + +#: make/make.md:328 +msgid "documentation](https://www.gnu.org/software/make/manual/make.html#Phony-Targets), " +msgstr "" + +#: make/make.md:329 +msgid "but for now it's enough to know that ``all`` and ``clean`` are typically " +msgstr "" + +#: make/make.md:330 +msgid "declared as phony." +msgstr "" + +#: make/make.md:332 +# blockquote, which can be cascaded +msgid "> Sidenote: another target that's typically phony is **test**, in case you " +msgstr "" + +#: make/make.md:333 +# blockquote, which can be cascaded +msgid "> have a directory of tests called **test** and want to have a target to run " +msgstr "" + +#: make/make.md:334 +# blockquote, which can be cascaded +msgid "> them that's also called **test**." +msgstr "" + +#: make/make.md:336 +# header +msgid "### Makefile no. 4 (Automatic Variables and Pattern Rules)" +msgstr "" + +#: make/make.md:338 +msgid "There's nothing wrong with the Makefile we have now, but it's somewhat verbose " +msgstr "" + +#: make/make.md:339 +msgid "because we've declared all the targets explicitly using separate rules. We can " +msgstr "" + +#: make/make.md:340 +msgid "simplify this by using [Automatic " +msgstr "" + +#: make/make.md:341 +msgid "Variables](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html) " +msgstr "" + +#: make/make.md:342 +msgid "and [Pattern " +msgstr "" + +#: make/make.md:343 +msgid "Rules](https://www.gnu.org/software/make/manual/html_node/Pattern-Rules.html#Pattern-Rules). " +msgstr "" + +#: make/make.md:345 +msgid "" +msgstr "" + +#: make/make.md:347 +msgid "**Automatic Variables.** With automatic variables we can use the names of the " +msgstr "" + +#: make/make.md:348 +msgid "prerequisites and targets in the recipe. Here's how we would do that for the " +msgstr "" + +#: make/make.md:349 +msgid "figure rules:" +msgstr "" + +#: make/make.md:351 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_1.png: data/input_file_1.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/figure_2.png: data/input_file_2.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:372 +msgid "We've replaced the input and output filenames in the recipes respectively by " +msgstr "" + +#: make/make.md:373 +msgid "``$<``, which denotes the *first* prerequisite and ``$@`` which denotes the " +msgstr "" + +#: make/make.md:374 +msgid "*target*. You can remember ``$<`` because it's like an arrow that points to " +msgstr "" + +#: make/make.md:375 +msgid "the beginning (*first* prerequisite), and you can remember ``$@`` (dollar " +msgstr "" + +#: make/make.md:376 +msgid "*at*) [as the target you're aiming " +msgstr "" + +#: make/make.md:377 +msgid "*at*](https://jameshfisher.com/2016/12/07/makefile-automatic-variables/)." +msgstr "" + +#: make/make.md:379 +msgid "There are more automatic variables that you could use, see [the " +msgstr "" + +#: make/make.md:380 +msgid "documentation](https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)." +msgstr "" + +#: make/make.md:382 +msgid "" +msgstr "" + +#: make/make.md:384 +msgid "**Pattern Rules.** Notice that the recipes for the figures have become " +msgstr "" + +#: make/make.md:385 +msgid "identical! Because we don't like to repeat ourselves, we can combine the two " +msgstr "" + +#: make/make.md:386 +msgid "rules into a single rule by using *pattern rules*. Pattern rules allow you to " +msgstr "" + +#: make/make.md:387 +msgid "use the ``%`` symbol as a wildcard and combine the two rules into one:" +msgstr "" + +#: make/make.md:389 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"output/figure_%.png: data/input_file_%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex output/figure_1.png output/figure_2.png\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../output/report.pdf\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f output/figure_*.pdf\n" +"```" +msgstr "" + +#: make/make.md:407 +msgid "The ``%`` symbol is now a wildcard that (in our case) takes the value ``1`` or " +msgstr "" + +#: make/make.md:408 +msgid "``2`` based on the input files in the ``data`` directory. You can check that " +msgstr "" + +#: make/make.md:409 +msgid "everything still works by running ``make clean`` followed by ``make``." +msgstr "" + +#: make/make.md:411 +msgid "An advantage of this is that if you now want to add another dataset, say " +msgstr "" + +#: make/make.md:412 +msgid "``input_file_3``, then you would only need to add that to the rule for the " +msgstr "" + +#: make/make.md:413 +msgid "report!" +msgstr "" + +#: make/make.md:416 +# header +msgid "### Makefile no. 5 (Wildcards and Path Substitution)" +msgstr "" + +#: make/make.md:418 +msgid "When Makefiles get more complex, you may want to use more advanced features " +msgstr "" + +#: make/make.md:419 +msgid "such as building outputs for all the files in an input directory. While " +msgstr "" + +#: make/make.md:420 +msgid "pattern rules will get you a long way, Make also has features for wildcards " +msgstr "" + +#: make/make.md:421 +msgid "and string or path manipulation for when pattern rules are insufficient." +msgstr "" + +#: make/make.md:423 +msgid "While previously our input files were numbered, we'll now switch to a scenario " +msgstr "" + +#: make/make.md:424 +msgid "where they have more meaningful names. Let's switch over to the ``big_data`` " +msgstr "" + +#: make/make.md:425 +msgid "branch:" +msgstr "" + +#: make/make.md:427 +# code block +msgid "```bash\n" +"$ git stash # stash the state of your working directory\n" +"$ git checkout big_data # checkout the big_data branch\n" +"```" +msgstr "" + +#: make/make.md:432 +msgid "The directory structure now looks like this:" +msgstr "" + +#: make/make.md:434 +# code block +msgid "```text\n" +"├── data/\n" +"│ ├── action.csv\n" +"│ ├── ...\n" +"│ ├── input_file_1.csv\n" +"│ ├── input_file_2.csv\n" +"│ ├── ...\n" +"│ └── western.csv\n" +"├── LICENSE\n" +"├── output/\n" +"├── README.md\n" +"├── report/\n" +"│ └── report.tex\n" +"└── scripts/\n" +" └── generate_histogram.py\n" +"```" +msgstr "" + +#: make/make.md:451 +msgid "As you can see, the **data** directory now contains additional input files " +msgstr "" + +#: make/make.md:452 +msgid "that are named more meaningfully (the data are IMBD movie ratings by genre). " +msgstr "" + +#: make/make.md:453 +msgid "Also, the **report.tex** file has been updated to work with the expected " +msgstr "" + +#: make/make.md:454 +msgid "figures." +msgstr "" + +#: make/make.md:456 +msgid "We'll adapt our Makefile to create a figure in the output directory called " +msgstr "" + +#: make/make.md:457 +msgid "``histogram_{genre}.png`` for each ``{genre}.csv`` file, while excluding the " +msgstr "" + +#: make/make.md:458 +msgid "``input_file_{N}.csv`` files." +msgstr "" + +#: make/make.md:460 +# blockquote, which can be cascaded +msgid "> Sidenote: if we were to remove the ``input_file_{N}.csv`` files, pattern " +msgstr "" + +#: make/make.md:461 +# blockquote, which can be cascaded +msgid "> rules would be sufficient here. This highlights that sometimes your " +msgstr "" + +#: make/make.md:462 +# blockquote, which can be cascaded +msgid "> directory structure and Makefile should be developed hand in hand." +msgstr "" + +#: make/make.md:464 +msgid "Before changing the Makefile, run" +msgstr "" + +#: make/make.md:466 +# code block +msgid "```bash\n" +"$ make clean\n" +"```" +msgstr "" + +#: make/make.md:469 +msgid "to remove the output files." +msgstr "" + +#: make/make.md:471 +msgid "We'll show the full Makefile first, and then describe the different lines in " +msgstr "" + +#: make/make.md:472 +msgid "more detail. The complete file is:" +msgstr "" + +#: make/make.md:474 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:498 +msgid "First, we use the ``wildcard`` function to create a variable that lists all " +msgstr "" + +#: make/make.md:499 +msgid "the CSV files in the data directory and one that lists only the old " +msgstr "" + +#: make/make.md:500 +msgid "``input_file_{N}.csv`` files:" +msgstr "" + +#: make/make.md:502 +# code block +msgid "```makefile\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"INPUT_CSV = $(wildcard data/input_file_*.csv)\n" +"```" +msgstr "" + +#: make/make.md:507 +msgid "A code convention for Makefiles is to use all capitals for variable names and " +msgstr "" + +#: make/make.md:508 +msgid "define them at the top of the file." +msgstr "" + +#: make/make.md:510 +msgid "Next, we create a variable to list only the data files that we're interested " +msgstr "" + +#: make/make.md:511 +msgid "in by filtering out the ``INPUT_CSV`` from ``ALL_CSV``:" +msgstr "" + +#: make/make.md:513 +# code block +msgid "```makefile\n" +"DATA = $(filter-out $(INPUT_CSV),$(ALL_CSV))\n" +"```" +msgstr "" + +#: make/make.md:517 +msgid "This line uses the " +msgstr "" + +#: make/make.md:518 +msgid "[``filter-out``](https://www.gnu.org/software/make/manual/make.html#index-filter_002dout) " +msgstr "" + +#: make/make.md:519 +msgid "function to remove items in the ``INPUT_CSV`` variable from the ``ALL_CSV`` " +msgstr "" + +#: make/make.md:520 +msgid "variable. Note that we use both the ``$( ... )`` syntax for functions and " +msgstr "" + +#: make/make.md:521 +msgid "variables. Finally, we'll use the ``DATA`` variable to create a ``FIGURES`` " +msgstr "" + +#: make/make.md:522 +msgid "variable with the desired output:" +msgstr "" + +#: make/make.md:524 +# code block +msgid "```makefile\n" +"FIGURES = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"```" +msgstr "" + +#: make/make.md:528 +msgid "Here we've used the " +msgstr "" + +#: make/make.md:529 +msgid "[``patsubst``](https://www.gnu.org/software/make/manual/make.html#index-patsubst-1) " +msgstr "" + +#: make/make.md:530 +msgid "function to transform the input in the ``DATA`` variable (that follows the " +msgstr "" + +#: make/make.md:531 +msgid "``data/{genre}.csv`` pattern) to the desired output filenames (using the " +msgstr "" + +#: make/make.md:532 +msgid "``output/figure_{genre}.png`` pattern). Notice that the ``%`` character marks " +msgstr "" + +#: make/make.md:533 +msgid "the part of the filename that will be the same in both the input and output." +msgstr "" + +#: make/make.md:535 +msgid "Now we use these variables for the figure generation rule as follows:" +msgstr "" + +#: make/make.md:537 +# code block +msgid "```makefile\n" +"$(FIGURES): output/figure_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"```" +msgstr "" + +#: make/make.md:542 +msgid "This rule again applies a pattern: it takes a list of targets (``$(FIGURES)``) " +msgstr "" + +#: make/make.md:543 +msgid "that all follow a given pattern (``output/figure_%.png``) and based on that " +msgstr "" + +#: make/make.md:544 +msgid "creates a prerequisite (``data/%.csv``). Such a pattern rule is slightly " +msgstr "" + +#: make/make.md:545 +msgid "different from the one we saw before because it uses two ``:`` symbols. It is " +msgstr "" + +#: make/make.md:546 +msgid "called a [static pattern " +msgstr "" + +#: make/make.md:547 +msgid "rule](https://www.gnu.org/software/make/manual/make.html#Static-Pattern)." +msgstr "" + +#: make/make.md:549 +msgid "Of course we have to update the ``report.pdf`` rule as well:" +msgstr "" + +#: make/make.md:551 +# code block +msgid "```makefile\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"```" +msgstr "" + +#: make/make.md:556 +msgid "and the ``clean`` rule:" +msgstr "" + +#: make/make.md:558 +# code block +msgid "```makefile\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(FIGURES)\n" +"```" +msgstr "" + +#: make/make.md:564 +msgid "If you run this Makefile, it will need to build 28 figures. You may want to " +msgstr "" + +#: make/make.md:565 +msgid "use the ``-j`` flag to ``make`` to build these targets **in parallel!**" +msgstr "" + +#: make/make.md:567 +#: make/make.md:984 +# code block +msgid "```bash\n" +"$ make -j 4\n" +"```" +msgstr "" + +#: make/make.md:571 +msgid "The ability to build targets in parallel is quite useful when your project has " +msgstr "" + +#: make/make.md:572 +msgid "many dependencies!" +msgstr "" + +#: make/make.md:574 +msgid "The resulting PDF file should now look like this:" +msgstr "" + +#: make/make.md:576 +msgid "![Report with all genres](../figures/make/report_all_genres.png)A compressed " +msgstr "" + +#: make/make.md:578 +msgid "view of the report with histograms for all genres." +msgstr "" + +#: make/make.md:580 +# header +msgid "### Debugging Makefiles" +msgstr "" + +#: make/make.md:582 +msgid "When writing a Makefile, it can sometimes be useful to be able to see the " +msgstr "" + +#: make/make.md:583 +msgid "values of variables to catch mistakes or bugs in the Makefile. To facilitate " +msgstr "" + +#: make/make.md:584 +msgid "this, Make contains two commands: ``info`` and ``error``, and there is a debug " +msgstr "" + +#: make/make.md:585 +msgid "mode to Make." +msgstr "" + +#: make/make.md:587 +msgid "With the ``info`` command you can print the current value of a variable to " +msgstr "" + +#: make/make.md:588 +msgid "stdout, while Make is processing the file. For instance, in the Makefile above " +msgstr "" + +#: make/make.md:589 +msgid "you could add:" +msgstr "" + +#: make/make.md:591 +# code block +msgid "```makefile\n" +"$(info $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:595 +msgid "This will print ``DATA = data/action.csv ... data/western.csv``. " +msgstr "" + +#: make/make.md:597 +msgid "With the ``error`` command you can stop the execution of Make at a certain " +msgstr "" + +#: make/make.md:598 +msgid "point in the Makefile. This is useful when you want to print the value of a " +msgstr "" + +#: make/make.md:599 +msgid "variable and not run Make any further:" +msgstr "" + +#: make/make.md:601 +# code block +msgid "```makefile\n" +"$(error $$DATA = $(DATA))\n" +"```" +msgstr "" + +#: make/make.md:605 +msgid "Finally, you can also debug the Makefile by running Make with the debug flag: " +msgstr "" + +#: make/make.md:606 +msgid "``make -d``. This will print all the rules (including built-in ones) that Make " +msgstr "" + +#: make/make.md:607 +msgid "tries for each of the targets, and whether or not a rule needs to be run." +msgstr "" + +#: make/make.md:609 +msgid "If you only want to print the rules that Make will run and not actually run " +msgstr "" + +#: make/make.md:610 +msgid "them, you can use ``make -n``. These last two options can also be combined, so " +msgstr "" + +#: make/make.md:611 +msgid "that you see the debug output and Make doesn't run anything: ``make -dn``." +msgstr "" + +#: make/make.md:613 +# header +msgid "## A Real Reproducible Paper using Make" +msgstr "" + +#: make/make.md:615 +msgid "In the tutorial above we used IMDB movie ratings for different genres as " +msgstr "" + +#: make/make.md:616 +msgid "example data. This data was obtained from a dataset [shared on " +msgstr "" + +#: make/make.md:617 +msgid "Kaggle](https://www.kaggle.com/orgesleka/imdbmovies#imdb.csv) as a CSV file. " +msgstr "" + +#: make/make.md:618 +msgid "The file looks like this:" +msgstr "" + +#: make/make.md:620 +# code block +msgid "```text\n" +"fn,tid,title,wordsInTitle,url,imdbRating,ratingCount,duration,year,type,nrOfWins,nrOfNominations,nrOfPhotos,nrOfNewsArticles,nrOfUserReviews,nrOfGenre,Action,Adult,Adventure,Animation,Biography,Comedy,Crime,Documentary,Drama,Family,Fantasy,FilmNoir,GameShow,History,Horror,Music,Musical,Mystery,News,RealityTV,Romance,SciFi,Short,Sport,TalkShow,Thriller,War,Western\n" +"titles01/tt0012349,tt0012349,Der Vagabund und das Kind (1921),der vagabund und das kind,http://www.imdb.com/title/tt0012349/,8.4,40550,3240,1921,video.movie,1,0,19,96,85,3,0,0,0,0,0,1,0,0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0015864,tt0015864,Goldrausch (1925),goldrausch,http://www.imdb.com/title/tt0015864/,8.3,45319,5700,1925,video.movie,2,1,35,110,122,3,0,0,1,0,0,1,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"titles01/tt0017136,tt0017136,Metropolis (1927),metropolis,http://www.imdb.com/title/tt0017136/,8.4,81007,9180,1927,video.movie,3,4,67,428,376,2,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0\n" +"titles01/tt0017925,tt0017925,Der General (1926),der general,http://www.imdb.com/title/tt0017925/,8.3,37521,6420,1926,video.movie,1,1,53,123,219,3,1,0,1,0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0\n" +"```" +msgstr "" + +#: make/make.md:628 +msgid "While on the surface this looks like a regular CSV file, when you try to open " +msgstr "" + +#: make/make.md:629 +msgid "it with the Python CSV library, or Pandas, or R's ``read_csv``, or even " +msgstr "" + +#: make/make.md:630 +msgid "``readr:read_csv``, the data is not loaded correctly. This happens because the " +msgstr "" + +#: make/make.md:631 +msgid "CSV file uses an escape character ``\\`` for movie names that have commas in " +msgstr "" + +#: make/make.md:632 +msgid "them and the CSV readers don't automatically detect this variation in the CSV " +msgstr "" + +#: make/make.md:633 +msgid "format. It turns out that this is quite a common issue for data scientists: " +msgstr "" + +#: make/make.md:634 +msgid "CSV files are often messy and use an uncommon *dialect*: such as strange delimiters and" +msgstr "" + +#: make/make.md:635 +msgid "uncommon quote characters. Collectively, data scientists waste quite " +msgstr "" + +#: make/make.md:636 +msgid "some time on these data wrangling issues where manual intervention is needed. " +msgstr "" + +#: make/make.md:637 +msgid "But this problem is also not that easy to solve: to a computer a CSV file is " +msgstr "" + +#: make/make.md:638 +msgid "simply a long string of characters and every dialect will give you *some* " +msgstr "" + +#: make/make.md:639 +msgid "table, so how do we determine the dialect accurately in general?" +msgstr "" + +#: make/make.md:641 +msgid "Recently, researchers from the Alan Turing Institute have presented a method " +msgstr "" + +#: make/make.md:642 +msgid "that achieves 97% accuracy on a large corpus of CSV files, with an improvement " +msgstr "" + +#: make/make.md:643 +msgid "of 21% over existing approaches on non-standard CSV files. This research was " +msgstr "" + +#: make/make.md:644 +msgid "made reproducible through the use of Make and is available through an online " +msgstr "" + +#: make/make.md:645 +msgid "repository: " +msgstr "" + +#: make/make.md:646 +msgid "[https://github.com/alan-turing-institute/CSV_Wrangling](https://github.com/alan-turing-institute/CSV_Wrangling)." +msgstr "" + +#: make/make.md:648 +msgid "Below we will briefly describe what the Makefile for such a project looks " +msgstr "" + +#: make/make.md:649 +msgid "like. For the complete file, please see the repository. The Makefile consists " +msgstr "" + +#: make/make.md:650 +msgid "of several sections:" +msgstr "" + +#: make/make.md:652 +# ordered list +msgid "1. Data collection: because the data is collected from public sources, the " +msgstr "" + +#: make/make.md:653 +msgid " repository contains a Python script that allows anyone to download the data " +msgstr "" + +#: make/make.md:654 +msgid " through a simple ``make data`` command." +msgstr "" + +#: make/make.md:656 +# ordered list +msgid "2. All the figures, tables, and constants used in the paper are generated " +msgstr "" + +#: make/make.md:657 +msgid " based on the results from the experiments. To make it easy to recreate all " +msgstr "" + +#: make/make.md:658 +msgid " results of a certain type, ``.PHONY`` targets are included that depend on " +msgstr "" + +#: make/make.md:659 +msgid " all results of that type (so you could run ``make figures``). The rules for " +msgstr "" + +#: make/make.md:660 +msgid " these outputs follow the same pattern as those for the figures in the " +msgstr "" + +#: make/make.md:661 +msgid " tutorial above. Tables are created as LaTeX files so they can be directly " +msgstr "" + +#: make/make.md:662 +msgid " included in the LaTeX source for the manuscript." +msgstr "" + +#: make/make.md:664 +# ordered list +msgid "3. The rules for the detection results follow a specific signature:" +msgstr "" + +#: make/make.md:666 +# code block +msgid " ```makefile\n" +" $(OUT_DETECT)/out_sniffer_%.json: $(OUT_PREPROCESS)/all_files_%.txt\n" +" python $(SCRIPT_DIR)/run_detector.py sniffer $(DETECTOR_OPTS) $< $@\n" +" ```" +msgstr "" + +#: make/make.md:671 +msgid " The ``%`` symbol is used to create outputs for both sources of CSV files " +msgstr "" + +#: make/make.md:672 +msgid " with a single rule (see [Pattern Rules](#pattern_rules)) and the rule uses " +msgstr "" + +#: make/make.md:673 +msgid " [automatic variables](#automatic_var) to extract the input and output " +msgstr "" + +#: make/make.md:674 +msgid " filenames." +msgstr "" + +#: make/make.md:676 +# ordered list +msgid "4. Some of the cleaning rules will remove output files that take a while to " +msgstr "" + +#: make/make.md:677 +msgid " create. Therefore, these depend on a special ``check_clean`` target that " +msgstr "" + +#: make/make.md:678 +msgid " asks the user to confirm before proceeding:" +msgstr "" + +#: make/make.md:680 +# code block +msgid " ```makefile\n" +" check_clean:\n" +" @echo -n \"Are you sure? [y/N]\" && read ans && [ $$ans == y ]\n" +" ```" +msgstr "" + +#: make/make.md:685 +msgid "It is important to emphasize that this file was not created in one go, but was " +msgstr "" + +#: make/make.md:686 +msgid "constructed iteratively. The Makefile started as a way to run several dialect " +msgstr "" + +#: make/make.md:687 +msgid "detection methods on a collection of input files and gradually grew to include " +msgstr "" + +#: make/make.md:688 +msgid "the creation of figures and tables from the result files. Thus the advice for " +msgstr "" + +#: make/make.md:689 +msgid "using Make for reproducibility is to *start small and start early*." +msgstr "" + +#: make/make.md:691 +msgid "The published Makefile in the repository does not contain the paper, but this " +msgstr "" + +#: make/make.md:692 +msgid "*is* included in the internal Makefile and follows the same structure as the " +msgstr "" + +#: make/make.md:693 +msgid "``report.pdf`` file in the tutorial above. This proved especially useful for " +msgstr "" + +#: make/make.md:694 +msgid "collaboration as only a single repository needed to be shared that contains " +msgstr "" + +#: make/make.md:695 +msgid "the code, the results, and the manuscript." +msgstr "" + +#: make/make.md:697 +# header +msgid "## Further Reading" +msgstr "" + +#: make/make.md:699 +# header +msgid "### Manual" +msgstr "" + +#: make/make.md:701 +# unordered list +msgid "- [The Official Make Reference " +msgstr "" + +#: make/make.md:702 +msgid " manual](https://www.gnu.org/software/make/manual/make.html)." +msgstr "" + +#: make/make.md:704 +# header +msgid "### Discussions" +msgstr "" + +#: make/make.md:706 +# unordered list +msgid "- [Discussion on Make on " +msgstr "" + +#: make/make.md:707 +msgid " HackerNews](https://news.ycombinator.com/item?id=15041986)." +msgstr "" + +#: make/make.md:709 +# unordered list +msgid "- [Recursive Make Considered " +msgstr "" + +#: make/make.md:710 +msgid " Harmful](http://aegis.sourceforge.net/auug97.pdf). This is a well-known " +msgstr "" + +#: make/make.md:711 +msgid " paper on why you shouldn't use nested makefiles. To summarise: if you do " +msgstr "" + +#: make/make.md:712 +msgid " this Make can't see the entire DAG and that leads to problems." +msgstr "" + +#: make/make.md:714 +# unordered list +msgid "- [Non-Recursive Make Considered " +msgstr "" + +#: make/make.md:715 +msgid " Harmful](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf): " +msgstr "" + +#: make/make.md:716 +msgid " This is a research paper describing the failings of Make for large and " +msgstr "" + +#: make/make.md:717 +msgid " complex builds." +msgstr "" + +#: make/make.md:719 +# header +msgid "### Blogs" +msgstr "" + +#: make/make.md:721 +msgid "Of course we are not the first to suggest the use of Make for reproducibility! " +msgstr "" + +#: make/make.md:722 +msgid "The blog posts cited below were found after the above tutorial was written, " +msgstr "" + +#: make/make.md:723 +msgid "but can add further information and examples." +msgstr "" + +#: make/make.md:725 +# unordered list +msgid "- [Reproducibility is " +msgstr "" + +#: make/make.md:726 +msgid " hard](https://kbroman.wordpress.com/tag/reproducible-research/). Discusses " +msgstr "" + +#: make/make.md:727 +msgid " making a research project reproducible using Make." +msgstr "" + +#: make/make.md:729 +# unordered list +msgid "- [GNU Make for Reproducible Data Analysis](http://zmjones.com/make/). Argues " +msgstr "" + +#: make/make.md:730 +msgid " for using Make for reproducible analysis in a similar vein as we do above." +msgstr "" + +#: make/make.md:732 +# unordered list +msgid "- [Reproducible Bioinformatics Pipelines using " +msgstr "" + +#: make/make.md:733 +msgid " Make](http://byronjsmith.com/make-bml/). A quite extensive tutorial on using " +msgstr "" + +#: make/make.md:734 +msgid " Make for data analysis." +msgstr "" + +#: make/make.md:736 +# unordered list +msgid "- [Automatic Data-analysis " +msgstr "" + +#: make/make.md:737 +msgid " Pipelines](http://stat545.com/automation04_make-activity.html). A similar " +msgstr "" + +#: make/make.md:738 +msgid " tutorial that uses R for the analysis." +msgstr "" + +#: make/make.md:740 +# header +msgid "### Tools" +msgstr "" + +#: make/make.md:742 +# unordered list +msgid "- Plot the DAG of the Makefile with " +msgstr "" + +#: make/make.md:743 +msgid " [makefile2graph](https://github.com/lindenb/makefile2graph)." +msgstr "" + +#: make/make.md:745 +# header +msgid "### Alternatives to Make" +msgstr "" + +#: make/make.md:747 +msgid "There are [many alternatives to " +msgstr "" + +#: make/make.md:748 +msgid "Make](https://en.wikipedia.org/wiki/List_of_build_automation_software). Below " +msgstr "" + +#: make/make.md:749 +msgid "are some that caught our eye and that might be worth a look." +msgstr "" + +#: make/make.md:751 +# unordered list +msgid "- [SnakeMake](https://snakemake.readthedocs.io/en/stable/). A Python3-based " +msgstr "" + +#: make/make.md:752 +msgid " alternative to Make. Snakemake supports multiple wildcards in filenames, " +msgstr "" + +#: make/make.md:753 +msgid " supports Python code in rules, and can run workflows on workstations, " +msgstr "" + +#: make/make.md:754 +msgid " clusters, the grid, and in the cloud without modification. " +msgstr "" + +#: make/make.md:756 +# unordered list +msgid "- [Tup](http://gittup.org/tup/index.html). A fast build system that processes " +msgstr "" + +#: make/make.md:757 +msgid " prerequisites bottom-up instead of Make's top-down. The speed looks " +msgstr "" + +#: make/make.md:758 +msgid " impressive and the paper describing it is interesting, but for small " +msgstr "" + +#: make/make.md:759 +msgid " projects Make's speed will not be a bottleneck. The Tupfile syntax is not " +msgstr "" + +#: make/make.md:760 +msgid " compatible with that of Makefiles." +msgstr "" + +#: make/make.md:762 +# unordered list +msgid "- [Bazel](https://www.bazel.build). An open-source version of Google's Blaze " +msgstr "" + +#: make/make.md:763 +msgid " build system." +msgstr "" + +#: make/make.md:765 +# unordered list +msgid "- [Buck](https://buckbuild.com/). Facebook's build system." +msgstr "" + +#: make/make.md:767 +# header +msgid "## Glossary" +msgstr "" + +#: make/make.md:769 +msgid "**Makefile:** a text file that contains the configuration for the build" +msgstr "" + +#: make/make.md:771 +msgid "**Rule:** an element of the Makefile that defines something that must be " +msgstr "" + +#: make/make.md:772 +msgid "built, usually consists of *targets*, *recipes*, and optionally, " +msgstr "" + +#: make/make.md:773 +msgid "*prerequisites*." +msgstr "" + +#: make/make.md:775 +msgid "**Target:** the outcome of a *rule* in a Makefile. It is usually a file. If it " +msgstr "" + +#: make/make.md:776 +msgid "is not a file, it's a *phony* target." +msgstr "" + +#: make/make.md:778 +msgid "**Recipe:** one or more shell commands that are executed by Make. Usually " +msgstr "" + +#: make/make.md:779 +msgid "these commands update the *target* of the *rule*." +msgstr "" + +#: make/make.md:781 +msgid "**Prerequisite:** the prerequisite(s) of a rule correspond to files or other " +msgstr "" + +#: make/make.md:782 +msgid "targets in the Makefile that must be up to date before the rule is run." +msgstr "" + +#: make/make.md:784 +msgid "**Phony:** a phony target is one that doesn't correspond to a file on the " +msgstr "" + +#: make/make.md:785 +msgid "filesystem. A target is marked as phony by making it a prerequisite of the " +msgstr "" + +#: make/make.md:786 +msgid "``.PHONY`` target." +msgstr "" + +#: make/make.md:788 +msgid "**Pattern:** A pattern rule is a rule that contains exactly one ``%`` " +msgstr "" + +#: make/make.md:789 +msgid "character in the target, which can be used to match a part of a filename." +msgstr "" + +#: make/make.md:791 +# header +msgid "## Appendix" +msgstr "" + +#: make/make.md:793 +# header +msgid "### Directed Acyclic Graph" +msgstr "" + +#: make/make.md:795 +msgid "A Directed Acyclic Graph (DAG) is a *graph* of nodes and edges that is:" +msgstr "" + +#: make/make.md:797 +# ordered list +msgid "1. *directed*: edges have a direction and you can only walk the graph in that " +msgstr "" + +#: make/make.md:798 +msgid " direction" +msgstr "" + +#: make/make.md:799 +# ordered list +msgid "2. *acyclic*: does not contain cycles: A can't depend on B when B depends on A." +msgstr "" + +#: make/make.md:801 +msgid "The latter property is of course quite handy for a build system. More " +msgstr "" + +#: make/make.md:802 +msgid "information on DAGs can be found on " +msgstr "" + +#: make/make.md:803 +msgid "[Wikipedia](https://en.wikipedia.org/wiki/Directed_acyclic_graph)." +msgstr "" + +#: make/make.md:805 +# header +msgid "### Installing Make" +msgstr "" + +#: make/make.md:807 +msgid "First, check if you have GNU Make installed already. In a terminal type:" +msgstr "" + +#: make/make.md:809 +# code block +msgid "```bash\n" +"$ make\n" +"```" +msgstr "" + +#: make/make.md:813 +msgid "If you get ``make: command not found`` (or similar), you don't have Make. If " +msgstr "" + +#: make/make.md:814 +msgid "you get ``make: *** No targets specified and no makefile found. Stop.`` you " +msgstr "" + +#: make/make.md:815 +msgid "do have Make." +msgstr "" + +#: make/make.md:817 +msgid "We'll be using **GNU Make** in this tutorial. Verify that this is what you " +msgstr "" + +#: make/make.md:818 +msgid "have by typing:" +msgstr "" + +#: make/make.md:820 +# code block +msgid "```bash\n" +"$ make --version\n" +"```" +msgstr "" + +#: make/make.md:824 +msgid "If you don't have GNU Make but have the BSD version, some things might not " +msgstr "" + +#: make/make.md:825 +msgid "work as expected and we recommend installing GNU Make." +msgstr "" + +#: make/make.md:827 +msgid "To install GNU Make, please follow these instructions:" +msgstr "" + +#: make/make.md:829 +# unordered list +msgid "- **Linux**: Use your package manager to install Make. For instance on Arch " +msgstr "" + +#: make/make.md:830 +msgid " Linux:" +msgstr "" + +#: make/make.md:832 +# code block +msgid " ```bash\n" +" $ sudo pacman -S make\n" +" ```" +msgstr "" + +#: make/make.md:836 +msgid " Ubuntu:" +msgstr "" + +#: make/make.md:837 +# code block +msgid " ```bash\n" +" $ sudo apt-get install build-essential\n" +" ```" +msgstr "" + +#: make/make.md:841 +# unordered list +msgid "- **MacOS**: If you have [Homebrew](https://brew.sh/) installed, it's simply:" +msgstr "" + +#: make/make.md:843 +# code block +msgid " ```bash\n" +" $ brew install make\n" +" ```" +msgstr "" + +#: make/make.md:847 +msgid " If you have a builtin Make implementation, please ensure that it's GNU Make " +msgstr "" + +#: make/make.md:848 +msgid " by checking ``make --version``." +msgstr "" + +#: make/make.md:850 +# header +msgid "### Advanced: Generating Rules using Call" +msgstr "" + +#: make/make.md:852 +msgid "*This section continues the tutorial above and demonstrates a feature of Make " +msgstr "" + +#: make/make.md:853 +msgid "for automatic generation of rules.*" +msgstr "" + +#: make/make.md:855 +msgid "In a data science pipeline, it may be quite common to apply multiple scripts " +msgstr "" + +#: make/make.md:856 +msgid "to the same data (for instance when you're comparing methods or testing " +msgstr "" + +#: make/make.md:857 +msgid "different parameters). In that case, it can become tedious to write a separate " +msgstr "" + +#: make/make.md:858 +msgid "rule for each script when only the script name changes. To simplify this " +msgstr "" + +#: make/make.md:859 +msgid "process, we can let Make expand a so-called [*canned* " +msgstr "" + +#: make/make.md:860 +msgid "recipe](https://www.gnu.org/software/make/manual/make.html#Canned-Recipes)." +msgstr "" + +#: make/make.md:862 +msgid "To follow along, switch to the ``canned`` branch:" +msgstr "" + +#: make/make.md:864 +# code block +msgid "```bash\n" +"$ make clean\n" +"$ git stash --all # note the '--all' flag so we also stash the Makefile\n" +"$ git checkout canned\n" +"```" +msgstr "" + +#: make/make.md:870 +msgid "On this branch you'll notice that there is a new script in the **scripts** " +msgstr "" + +#: make/make.md:871 +msgid "directory called ``generate_qqplot.py``. This script works similarly to the " +msgstr "" + +#: make/make.md:872 +msgid "``generate_histogram.py`` script (it has the same command line syntax), but it " +msgstr "" + +#: make/make.md:873 +msgid "generates a [QQ-plot](https://en.wikipedia.org/wiki/Q%E2%80%93Q_plot). The " +msgstr "" + +#: make/make.md:874 +msgid "**report.tex** file has also been updated to incorporate these plots." +msgstr "" + +#: make/make.md:876 +msgid "After switching to the ``canned`` branch there will be a Makefile in the " +msgstr "" + +#: make/make.md:877 +msgid "repository that contains a separate rule for generating the QQ-plots. This " +msgstr "" + +#: make/make.md:878 +msgid "Makefile looks like this:" +msgstr "" + +#: make/make.md:880 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst data/%.csv,output/figure_%.png,$(DATA))\n" +"QQPLOTS = $(patsubst data/%.csv,output/qqplot_%.png,$(DATA))\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"$(HISTOGRAMS): output/histogram_%.png: data/%.csv scripts/generate_histogram.py\n" +" python scripts/generate_histogram.py -i $< -o $@\n" +"\n" +"$(QQPLOTS): output/qqplot_%.png: data/%.csv scripts/generate_qqplot.py\n" +" python scripts/generate_qqplot.py -i $< -o $@\n" +"\n" +"output/report.pdf: report/report.tex $(FIGURES)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:907 +msgid "You'll notice that the rules for histograms and QQ-plots are very similar." +msgstr "" + +#: make/make.md:909 +msgid "As the number of scripts that you want to run on your data grows, this may " +msgstr "" + +#: make/make.md:910 +msgid "lead to a large number of rules in the Makefile that are almost exactly the " +msgstr "" + +#: make/make.md:911 +msgid "same. We can simplify this by creating a [*canned " +msgstr "" + +#: make/make.md:912 +msgid "recipe*](https://www.gnu.org/software/make/manual/html_node/Canned-Recipes.html) " +msgstr "" + +#: make/make.md:913 +msgid "that takes both the name of the script and the name of the genre as input:" +msgstr "" + +#: make/make.md:915 +# code block +msgid "```makefile\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"```" +msgstr "" + +#: make/make.md:922 +msgid "Note that in this recipe we use ``$(1)`` for either ``histogram`` or " +msgstr "" + +#: make/make.md:923 +msgid "``qqplot`` and ``$(2)`` for the genre. These correspond to the expected " +msgstr "" + +#: make/make.md:924 +msgid "function arguments to the ``run-script-on-data`` canned recipe. Also, notice " +msgstr "" + +#: make/make.md:925 +msgid "that we use ``$$<`` and ``$$@`` in the actual recipe, with two ``$`` symbols " +msgstr "" + +#: make/make.md:926 +msgid "for escaping. To actually create all the targets, we need a line that calls " +msgstr "" + +#: make/make.md:927 +msgid "this canned recipe. In our case, we use a double for loop over the genres and " +msgstr "" + +#: make/make.md:928 +msgid "the scripts:" +msgstr "" + +#: make/make.md:930 +# code block +msgid "```makefile\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre))) \\\n" +" ) \\\n" +")\n" +"```" +msgstr "" + +#: make/make.md:938 +msgid "In these lines the ``\\`` character is used for continuing long lines." +msgstr "" + +#: make/make.md:940 +msgid "The full Makefile then becomes:" +msgstr "" + +#: make/make.md:942 +# code block +msgid "```makefile\n" +"# Makefile for analysis report\n" +"#\n" +"\n" +"ALL_CSV = $(wildcard data/*.csv)\n" +"DATA = $(filter-out $(wildcard data/input_file_*.csv),$(ALL_CSV))\n" +"HISTOGRAMS = $(patsubst %,output/histogram_%.png,$(GENRES))\n" +"QQPLOTS = $(patsubst %,output/qqplot_%.png,$(GENRES))\n" +"\n" +"GENRES = $(patsubst data/%.csv,%,$(DATA))\n" +"SCRIPTS = histogram qqplot\n" +"\n" +".PHONY: all clean\n" +"\n" +"all: output/report.pdf\n" +"\n" +"define run-script-on-data\n" +"output/$(1)_$(2).png: data/$(2).csv scripts/generate_$(1).py\n" +" python scripts/generate_$(1).py -i $$< -o $$@\n" +"endef\n" +"\n" +"$(foreach genre,$(GENRES),\\\n" +" $(foreach script,$(SCRIPTS),\\\n" +" $(eval $(call run-script-on-data,$(script),$(genre)))\\\n" +" )\\\n" +")\n" +"\n" +"output/report.pdf: report/report.tex $(HISTOGRAMS) $(QQPLOTS)\n" +" cd report/ && pdflatex report.tex && mv report.pdf ../$@\n" +"\n" +"clean:\n" +" rm -f output/report.pdf\n" +" rm -f $(HISTOGRAMS) $(QQPLOTS)\n" +"```" +msgstr "" + +#: make/make.md:977 +msgid "Note that we've added a ``SCRIPTS`` variable with the ``histogram`` and " +msgstr "" + +#: make/make.md:978 +msgid "``qqplot`` names. If we were to add another script that follows the same " +msgstr "" + +#: make/make.md:979 +msgid "pattern as these two, we would only need to add it to the ``SCRIPTS`` " +msgstr "" + +#: make/make.md:980 +msgid "variable." +msgstr "" + +#: make/make.md:982 +msgid "To build all of this, run" +msgstr "" + diff --git a/book/content/po/open_research.es.po b/book/content/po/open_research.es.po new file mode 100644 index 00000000000..beb0296ffc2 --- /dev/null +++ b/book/content/po/open_research.es.po @@ -0,0 +1,2493 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: open_research/01/opendata.md:44 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: open_research/01/opendata.md:57 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: open_research/02/opensourcesoftware.md:79 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: open_research/02/opensourcesoftware.md:80 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:84 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: open_research/02/opensourcesoftware.md:85 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:86 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: open_research/07/resources.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: open_research/07/resources.md:13 +#: open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: open_research/07/resources.md:34 +# header +msgid "## What to learn next" +msgstr "" + +#: open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: open_research/07/resources.md:38 +# header +msgid "## Further reading" +msgstr "" + +#: open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: open_research/07/resources.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: open_research/07/resources.md:67 +# header +msgid "## Bibliography" +msgstr "" + +#: open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: open_research/open_research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: open_research/open_research.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: open_research/open_research.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: open_research/open_research.md:11 +# header +msgid "## Table of contents" +msgstr "" + +#: open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: open_research/open_research.md:65 +# header +msgid "## Summary" +msgstr "" + +#: open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: open_research/open_research.md:91 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + diff --git a/book/content/po/open_research.pot b/book/content/po/open_research.pot new file mode 100644 index 00000000000..c41b7368d54 --- /dev/null +++ b/book/content/po/open_research.pot @@ -0,0 +1,2493 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: open_research/01/opendata.md:44 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: open_research/01/opendata.md:57 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: open_research/02/opensourcesoftware.md:79 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: open_research/02/opensourcesoftware.md:80 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:84 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: open_research/02/opensourcesoftware.md:85 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:86 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: open_research/07/resources.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: open_research/07/resources.md:13 +#: open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: open_research/07/resources.md:34 +# header +msgid "## What to learn next" +msgstr "" + +#: open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: open_research/07/resources.md:38 +# header +msgid "## Further reading" +msgstr "" + +#: open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: open_research/07/resources.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: open_research/07/resources.md:67 +# header +msgid "## Bibliography" +msgstr "" + +#: open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: open_research/open_research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: open_research/open_research.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: open_research/open_research.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: open_research/open_research.md:11 +# header +msgid "## Table of contents" +msgstr "" + +#: open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: open_research/open_research.md:65 +# header +msgid "## Summary" +msgstr "" + +#: open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: open_research/open_research.md:91 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + diff --git a/book/content/po/open_research.tr.po b/book/content/po/open_research.tr.po new file mode 100644 index 00000000000..c41b7368d54 --- /dev/null +++ b/book/content/po/open_research.tr.po @@ -0,0 +1,2493 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: open_research/01/opendata.md:44 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: open_research/01/opendata.md:57 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: open_research/02/opensourcesoftware.md:79 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: open_research/02/opensourcesoftware.md:80 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:84 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: open_research/02/opensourcesoftware.md:85 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:86 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: open_research/07/resources.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: open_research/07/resources.md:13 +#: open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: open_research/07/resources.md:34 +# header +msgid "## What to learn next" +msgstr "" + +#: open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: open_research/07/resources.md:38 +# header +msgid "## Further reading" +msgstr "" + +#: open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: open_research/07/resources.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: open_research/07/resources.md:67 +# header +msgid "## Bibliography" +msgstr "" + +#: open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: open_research/open_research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: open_research/open_research.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: open_research/open_research.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: open_research/open_research.md:11 +# header +msgid "## Table of contents" +msgstr "" + +#: open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: open_research/open_research.md:65 +# header +msgid "## Summary" +msgstr "" + +#: open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: open_research/open_research.md:91 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + diff --git a/book/content/po/open_research.zh_CN.po b/book/content/po/open_research.zh_CN.po new file mode 100644 index 00000000000..dc5c02a6c43 --- /dev/null +++ b/book/content/po/open_research.zh_CN.po @@ -0,0 +1,2494 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: open_research/01/opendata.md:1 +# header +msgid "## Open data" +msgstr "" + +#: open_research/01/opendata.md:3 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fuelled by data and information. This transformation has enormous potential to foster more transparent, accountable, efficient, responsive, and effective research." +msgstr "" + +#: open_research/01/opendata.md:4 +msgid "Only a very small proportion of the original data is published in conventional journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of data sharing is an obstacle to international research (be it academic, governmental, or commercial) for two main reasons:" +msgstr "" + +#: open_research/01/opendata.md:6 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a study without the original data." +msgstr "" + +#: open_research/01/opendata.md:7 +# ordered list +msgid "2. The data cannot be reused or incorporated into new work by other researchers if they cannot obtain access to it." +msgstr "" + +#: open_research/01/opendata.md:9 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and expansion of effective, efficient research programs. Open data is crucial to meeting these objectives." +msgstr "" + +#: open_research/01/opendata.md:10 +msgid "Open data is freely available on the internet and any user is permitted to download, copy, analyse, re-process, and re-use it for any other purpose with minimal financial, legal, and technical barriers." +msgstr "" + +#: open_research/01/opendata.md:11 +msgid "This represents a real shift in how research works. At the moment anyone who wishes to use data from a researcher often has to contact that researcher and make a request. \"Open by default\" turns this on its head and says that there should be a presumption of publication for all. If access to data is restricted, for instance due to security reasons, the justification for this should be made clear." +msgstr "" + +#: open_research/01/opendata.md:12 +msgid "Free access to, and subsequent use of, data is of significant value to society and the economy, and that data should, therefore, be open by default. So, how do you go about making your data open?" +msgstr "" + +#: open_research/01/opendata.md:14 +# header +msgid "### Steps to make your data open" +msgstr "" + +#: open_research/01/opendata.md:16 +# header +msgid "#### Step 1: Make your data available" +msgstr "" + +#: open_research/01/opendata.md:18 +msgid "Put your data online. It should be easily discoverable and accessible, and made available without bureaucratic or administrative barriers, which can deter people from accessing the data. Choose a location to store the data which will ensure historical copies of datasets are preserved, archived, and kept accessible as long as they retain value. Whenever possible, researchers should provide data in its original, unmodified form." +msgstr "" + +#: open_research/01/opendata.md:20 +msgid "Data should be free of charge, under [an open licence](https://fossbytes.com/open-sources-license-type/), (for example, those developed by Creative Commons) so it can be reused and remixed by other researchers. The data should be available as a whole and at no more than a reasonable reproduction cost. That is, no expensive piece of software should be required to read the file as this may obstruct researchers who wish to work with the dataset." +msgstr "" + +#: open_research/01/opendata.md:22 +# header +msgid "#### Step 2: Make your data easy to understand" +msgstr "" + +#: open_research/01/opendata.md:24 +msgid "Having data available is of no use if it cannot be understood. For example, a table of numbers is useless if there are no headings which describe the contents of the rows and columns. Therefore you should ensure that open datasets include consistent core metadata, and that the data is fully described. This requires that all documentation accompanying data is written in clear, plain language, and that data users have sufficient information to understand the source, strengths, weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: open_research/01/opendata.md:26 +# header +msgid "#### Step 3: Make your data easy to use" +msgstr "" + +#: open_research/01/opendata.md:28 +msgid "The data should be made available in a modifiable, machine-readable format so that it can be effectively used and manipulated." +msgstr "" + +#: open_research/01/opendata.md:29 +msgid "It is also important to think about the file formats that information is provided in. Data should be presented in structured and standardized formats to support interoperability, traceability, and effective reuse. In many cases, this will include providing data in multiple, standardized formats, so that it can be processed by computers and used by people." +msgstr "" + +#: open_research/01/opendata.md:31 +# header +msgid "#### Step 4: Make your data citeable" +msgstr "" + +#: open_research/01/opendata.md:33 +msgid "Data should be considered a legitimate, citable product of research. Making data citeable (and citing data yourself) facilitates the giving of scholarly credit; in scholarly literature, whenever and wherever a claim relies upon data, the corresponding data should be cited. Data citations facilitate identification of, access to, and verification of the specific data that support a claim, making it possible to reproduce the underlying analysis. You should ensure that anyone who wishes to cite a dataset that you host has access to a persistent identifier in order to do so." +msgstr "" + +#: open_research/01/opendata.md:35 +msgid "A data citation should include a persistent method for identification that is unique, and widely understandable by a community. There are several types of persistent identifier that could be used to identify datasets: examples include Handles, Archival Resource Keys (ARKs) and Persistent URLs (PURLs), all of which can be resolved to an Internet location. The scheme that is gaining most traction is the Digital Object Identifier (DOI)." +msgstr "" + +#: open_research/01/opendata.md:37 +msgid "" +msgstr "" + +#: open_research/01/opendata.md:38 +msgid "The DOI System is an identifier scheme administered by the International DOI Foundation. The task of managing DOI registers is delegated to registration agencies (for a list, see [here](http://www.doi.org/registration_agencies.html)) that each specialise in a type of resource. For research datasets, the registration agency is the [DataCite Consortium](https://www.datacite.org/). Among the services it provides are human and machine interfaces for simple end-user administration of DOI registrations. DataCite also collects metadata about each dataset it registers so they can be more easily understood and identified. Any repository wishing to register DOIs needs to obtain a username and password from DataCite to gain access to the registration service. While best practice has yet to emerge on some matters, certain conventions are already becoming established." +msgstr "" + +#: open_research/01/opendata.md:40 +msgid "In particular, when organisations register a DOI for a resource, they should not introduce semantic elements into the suffix, especially not metadata that might change over time (for example, publisher, archive, owner). Assign identifiers to static datasets only when no further changes or corrections are expected (such as after quality control checks are complete). As DOIs are used to cite data as evidence, the resource to which a DOI points should also remain unchanged, with any new version receiving a new DOI." +msgstr "" + +#: open_research/01/opendata.md:42 +msgid "Furthermore, whichever identifier scheme you pick make sure it allows the identifier to be resolved to a URL. This URL should belong to a landing page that contains descriptive information about the dataset, as well as links or instructions for accessing it. You should also ensure that datasets are made citable and identifiable at an appropriate level of granularity. For example, it would be no use citing CERN's entire data repository as someone attempting to reproduce your work would not be able to find the data used in a specific piece of work without considerable difficulty. Where possible you should be able to cite the data used, and only the data used." +msgstr "" + +#: open_research/01/opendata.md:44 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: open_research/01/opendata.md:46 +msgid "Sometimes it may not be possible to make data publicly available in its entirety or even in part. There are two main reasons this may be the case:" +msgstr "" + +#: open_research/01/opendata.md:48 +# header +msgid "#### Privacy" +msgstr "" + +#: open_research/01/opendata.md:50 +msgid "Many fields of research involve working with sensitive personal data, medical research being the most obvious example." +msgstr "" + +#: open_research/01/opendata.md:51 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly difficult due to technical progress, growing computational power and – ironically – more open data. For example, reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a set of (common) properties that are – in their combination – so specific that they can be used to identify individuals." +msgstr "" + +#: open_research/01/opendata.md:53 +msgid "Preserving privacy may still be possible if partial or generalised datasets are provided." +msgstr "" + +#: open_research/01/opendata.md:54 +msgid "For example, providing age bands instead of birth date or only the first two digits of postal codes." +msgstr "" + +#: open_research/01/opendata.md:55 +msgid "It may also be possible to provide the data in such a format that researchers can query it whist keeping the data itself closed, for example, a user may be able to send a query to retrieve the mean of a dataset, but not be able to access any of the individual datapoints." +msgstr "" + +#: open_research/01/opendata.md:57 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: open_research/01/opendata.md:59 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if commercially sensitive information is disclosed, it will damage the company’s commercial interests and undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with some protection of information: if a company spends time and money developing something new, the details of which are then made public, then its competitors can easily copy it without having to invest the same resources. The result is that no-one would innovate in the first place. Similarly, governments are often unwilling to publish data that relates to issues such as national security due to public safety concerns." +msgstr "" + +#: open_research/01/opendata.md:61 +msgid "In such cases it may not be possible to make data open, or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: open_research/02/opensourcesoftware.md:1 +# header +msgid "## Open source software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:3 +# header +msgid "### What is open source software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:5 +msgid "When a project is open source anybody can view, use, modify, and distribute the project for any purpose." +msgstr "" + +#: open_research/02/opensourcesoftware.md:6 +msgid "These permissions are enforced through an open source licence." +msgstr "" + +#: open_research/02/opensourcesoftware.md:7 +msgid "Open source is powerful because it lowers the barriers to adoption, allowing ideas to spread quickly." +msgstr "" + +#: open_research/02/opensourcesoftware.md:8 +msgid "In its most basic form, open sourcing your software simply means putting your code online where it can be viewed and reused by others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:10 +msgid "Many of the most widely used research software is open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:11 +msgid "Perhaps the paradigmatic example is the scikit-learn Python package for machine learning (Pedregosa et al., 2011), which, in the space of just over five years, has attracted over 500 unique contributors, 20,000 individual code contributions, and 2,500 article citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:12 +msgid "Producing a comparable package using a traditional closed-source approach would likely not be feasible, and would, at the very least, have required a budget of tens of millions of dollars." +msgstr "" + +#: open_research/02/opensourcesoftware.md:13 +msgid "While scikit-learn is clearly an outlier, hundreds of other open source packages that support much more domain-specific needs depend in a similar fashion on unsolicited community contributions, for example, the NIPY (neuroimaging in Python) group of projects in neuroimaging (Gorgolewski et al., 2016)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:14 +msgid "Importantly, such contributions not only result in new functionality from which the broader community can benefit, but also regularly provide their respective authors with greater community recognition, and lead to new project and employment opportunities." +msgstr "" + +#: open_research/02/opensourcesoftware.md:16 +msgid "Researchers that make use of open source software often make changes to them such as adding features they need for their own research, or fixing bugs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:17 +msgid "They can then contribute these improvements back to the main project so the wider community can take advantage of them." +msgstr "" + +#: open_research/02/opensourcesoftware.md:19 +# header +msgid "### How running and contributing to open source software projects benefits you" +msgstr "" + +#: open_research/02/opensourcesoftware.md:21 +# unordered list +msgid "- Improve existing skills: Whether it is coding, user interface design, graphic design, writing, or organizing, if you are looking for practice, there is a task for you on an open source software project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:22 +msgid "Further, open source necessitates cleaner, more maintainable code to enable collaboration between potentially thousands of people who may never meet." +msgstr "" + +#: open_research/02/opensourcesoftware.md:23 +msgid "This helps to build and maintain good coding habits." +msgstr "" + +#: open_research/02/opensourcesoftware.md:24 +msgid "Not to be underestimated are the people skills you can develop on open source software projects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:25 +msgid "Open source offers opportunities to practice leadership and management skills, such as resolving conflicts, organising teams of people, and prioritising work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:26 +# unordered list +msgid "- Advance your career: By definition, all of your open source work is public and this presents opportunities:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:27 +# unordered list +msgid " - Demonstrate technical ability: Technical interviews traditionally involve working on a simulated problem that can be tackled in a set amount of time with little additional context." +msgstr "" + +#: open_research/02/opensourcesoftware.md:28 +msgid " Such simulations, by definition, are not real world use cases, nor do they show what working with an applicant would be like." +msgstr "" + +#: open_research/02/opensourcesoftware.md:29 +msgid " Open source provides visibility into both how a candidate solves problems, and how they work with others." +msgstr "" + +#: open_research/02/opensourcesoftware.md:30 +msgid " You make a much more appealing employee if an employer can see the quality of your work and see you working with others over a long period of time rather than taking a chance on a single short, high-stress case which may not play to your strengths." +msgstr "" + +#: open_research/02/opensourcesoftware.md:31 +# unordered list +msgid " - Reputation: Becoming an active member of the open source community can gain you a positive reputation which may bolster future job prospects." +msgstr "" + +#: open_research/02/opensourcesoftware.md:32 +# unordered list +msgid "- Meet people with similar interests: Open source software projects with warm, welcoming communities keep people coming back for years and many people form lifelong friendships through their participation in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:33 +# unordered list +msgid "- Find mentors and teach others: Working with others on a shared project means you will have to explain how you do things, as well as ask other people for help. The acts of learning and teaching can be a fulfilling activity for everyone involved." +msgstr "" + +#: open_research/02/opensourcesoftware.md:35 +# header +msgid "#### Making your own work open source" +msgstr "" + +#: open_research/02/opensourcesoftware.md:37 +# unordered list +msgid "- Re-usability: Making your work openly available for re-use makes it easier for others to incorporate into their own research. If you make your software citeable, for example via a [DOI](doi_system) this can increase your citations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:38 +# unordered list +msgid "- When you write closed source software, the only developers that can potentially detect, diagnose, triage, and resolve software bugs are those that have a copy of the code." +msgstr "" + +#: open_research/02/opensourcesoftware.md:39 +msgid "If your project is open the number of potentially contributing developers and thus the potential knowledge pool is orders of magnitude larger." +msgstr "" + +#: open_research/02/opensourcesoftware.md:40 +# unordered list +msgid "- Feedback: Making your work open enables you to get feedback and improve your project in way you may never have thought of alone." +msgstr "" + +#: open_research/02/opensourcesoftware.md:41 +# unordered list +msgid "- Accountability: There is an argument that any software developed using government money should be open source by default; if the public has paid for its development they have a right to make use of it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:42 +msgid "If your work is government funded making it open is a step you can take towards government openness and accountability." +msgstr "" + +#: open_research/02/opensourcesoftware.md:44 +# header +msgid "#### Contributing to others' open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:46 +# unordered list +msgid "- It is empowering to be able to make changes, even small ones: You do not have to become a lifelong contributor to enjoy participating in open source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:47 +msgid "Have you ever seen a typo on a website, and wished someone would fix it?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:48 +msgid "On an open source software project, you can do just that." +msgstr "" + +#: open_research/02/opensourcesoftware.md:49 +msgid "Open source helps people feel agency over their lives and how they experience the world, and that in itself is gratifying." +msgstr "" + +#: open_research/02/opensourcesoftware.md:50 +# unordered list +msgid "- It is fun:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:51 +msgid "Open source provides an endless, ever-changing set of Rubix cubes for you to solve on weekends. Just like puzzles, both crossword and jigsaw, open source provides bite-sized intellectual escapes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:53 +# header +msgid "### How open source software benefits research" +msgstr "" + +#: open_research/02/opensourcesoftware.md:55 +msgid "Open source software projects primarily benefit research by allowing researchers to take advantage of each others' work. This enables researchers to apply their efforts to high-value work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:56 +msgid "It is sometimes said that \"all the easy problems have already been solved\"." +msgstr "" + +#: open_research/02/opensourcesoftware.md:57 +msgid "Blogging, content management, and operating systems are all problems with established (and mainstream) open source solutions, to name a few." +msgstr "" + +#: open_research/02/opensourcesoftware.md:58 +msgid "While developers could spend their time reinventing wheels that the open source community have already perfected, it is highly preferable to use the world's best wheel, especially when that wheel comes at no cost to you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:59 +msgid "This frees researchers up to work on yet-unsolved challenges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:60 +msgid "This reduces duplication of effort and allows researchers to focus on the work they're actually interested in." +msgstr "" + +#: open_research/02/opensourcesoftware.md:62 +msgid "Working openly also allows any number of researchers to collaborate on projects that could not possibly be developed by single researchers/research groups." +msgstr "" + +#: open_research/02/opensourcesoftware.md:63 +msgid "Examples include [Linux](https://www.linux.org/) operating systems, Python packages such as [scipy](https://www.scipy.org/) and [numpy](http://www.numpy.org/), and the machine learning library [TensorFlow](https://www.tensorflow.org/). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:65 +# header +msgid "### How to run your own open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:67 +msgid "You can open source an idea, a work in progress, or after years of being closed source." +msgstr "" + +#: open_research/02/opensourcesoftware.md:68 +msgid "At the most basic level all you need to do is put your code online somewhere that is likely to last a long time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:69 +msgid "You can make your code citeable by assigning it a DOI (as discussed in the section on [making data citeable](#citing_data)). " +msgstr "" + +#: open_research/02/opensourcesoftware.md:70 +msgid "This helps ensure that you get proper credit if people use or build upon your work." +msgstr "" + +#: open_research/02/opensourcesoftware.md:72 +msgid "A popular place to make your code available is GitHub (see the chapter on [version control](/version_control/version_control)). You must include a licence file stating that anyone has permission to use, copy, and modify your work. Without this no one can legally use your work and so it isn't open source. [This](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best licence for your project. There are also a few other files you should include with your code, as described below." +msgstr "" + +#: open_research/02/opensourcesoftware.md:74 +# header +msgid "#### Welcome users by adding information to your README" +msgstr "" + +#: open_research/02/opensourcesoftware.md:76 +msgid "You should include a readme file where you include useful information about what the project is, how to use it, and how to contribute to it. Here's a list of the main things a readme should include:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:78 +# unordered list +msgid "- The project name and what it is: This will greatly help someone that comes across it to get an idea of the project. Include a few key points that describe the main features of the project and what are the main features you're implementing." +msgstr "" + +#: open_research/02/opensourcesoftware.md:79 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: open_research/02/opensourcesoftware.md:80 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:81 +msgid "Nevertheless, it is a total waste of both of your resources to start figuring out how to just get started with the project. This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:82 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you'll quickly save hours of work in the future." +msgstr "" + +#: open_research/02/opensourcesoftware.md:83 +# unordered list +msgid "- Instructions for how to run the code and any associated tests: If you've been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: open_research/02/opensourcesoftware.md:84 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: open_research/02/opensourcesoftware.md:85 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:86 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: open_research/02/opensourcesoftware.md:88 +msgid "If you intend for other people to collaborate on your project (as opposed to just making your code available and considering it complete) then you should include contributing guidelines and most likely a code of conduct." +msgstr "" + +#: open_research/02/opensourcesoftware.md:90 +# header +msgid "#### Contributing guidelines" +msgstr "" + +#: open_research/02/opensourcesoftware.md:92 +msgid "Contributing guidelines tell your audience how to participate in your project. For example, you might include information on:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:94 +# unordered list +msgid "- How to file a bug report." +msgstr "" + +#: open_research/02/opensourcesoftware.md:95 +# unordered list +msgid "- How to suggest a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:96 +# unordered list +msgid "- Your roadmap or vision for the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:97 +# unordered list +msgid "- How contributors should (or should not) get in touch with you." +msgstr "" + +#: open_research/02/opensourcesoftware.md:99 +msgid "Using a warm, friendly tone and offering specific suggestions for contributions (such as writing documentation, or making a website) can go a long way in making newcomers feel welcomed and excited to participate." +msgstr "" + +#: open_research/02/opensourcesoftware.md:100 +msgid "For example, [Active Admin](https://activeadmin.info/index.html) starts its [contributing guide](https://github.com/activeadmin/activeadmin/blob/master/CONTRIBUTING.md) with: \"First off, thank you for considering contributing to Active Admin. It’s people like you that make Active Admin such a great tool.\"" +msgstr "" + +#: open_research/02/opensourcesoftware.md:102 +msgid "In the earliest stages of your project, your contributing guidelines file can be simple." +msgstr "" + +#: open_research/02/opensourcesoftware.md:103 +msgid "You should always explain how to report bugs or file issues, and any technical requirements (like tests) to make a contribution." +msgstr "" + +#: open_research/02/opensourcesoftware.md:104 +msgid "Over time, you might add other frequently asked questions here or in your readme file." +msgstr "" + +#: open_research/02/opensourcesoftware.md:105 +msgid "Writing down this information means fewer people will ask you the same questions over and over again." +msgstr "" + +#: open_research/02/opensourcesoftware.md:106 +msgid "It's also a good idea to link to your contributing guidelines file from your readme, so more people see it." +msgstr "" + +#: open_research/02/opensourcesoftware.md:108 +# header +msgid "#### Code of conduct" +msgstr "" + +#: open_research/02/opensourcesoftware.md:110 +msgid "A code of conduct helps set ground rules for behaviour for your project's participants." +msgstr "" + +#: open_research/02/opensourcesoftware.md:111 +msgid "This is especially valuable if you are launching an open source project for a community or company." +msgstr "" + +#: open_research/02/opensourcesoftware.md:112 +msgid "A code of conduct empowers you to facilitate healthy, constructive community behaviour, which will reduce your stress as a maintainer." +msgstr "" + +#: open_research/02/opensourcesoftware.md:113 +msgid "In addition to communicating how you expect participants to behave, a code of conduct also tends to describe who these expectations apply to, when they apply, and what to do if a violation occurs." +msgstr "" + +#: open_research/02/opensourcesoftware.md:115 +msgid "Much like open source licences, there are also emerging standards for codes of conduct, so you don't have to write your own. The [Contributor Covenant](https://contributor-covenant.org/) is a drop-in code of conduct that is used by [over 40,000 open source projects](https://www.contributor-covenant.org/adopters). No matter which text you use, you should be prepared to enforce your code of conduct when necessary." +msgstr "" + +#: open_research/02/opensourcesoftware.md:117 +msgid "Keep the file in your project's root directory so it's easy to find, and link to it from your readme." +msgstr "" + +#: open_research/02/opensourcesoftware.md:119 +# header +msgid "### How to contribute to other's open source software projects" +msgstr "" + +#: open_research/02/opensourcesoftware.md:121 +# header +msgid "#### Anatomy of an open source software project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:123 +msgid "Every open source community is different. That said, many open source software projects follow a similar organizational structure. Understanding the different community roles and overall process will help you get quickly oriented to any new project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:125 +msgid "A typical open source software project has the following types of people:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:127 +# unordered list +msgid "- Author: The person/s or organization that created the project" +msgstr "" + +#: open_research/02/opensourcesoftware.md:128 +# unordered list +msgid "- Owner: The person/s who has administrative ownership over the organization or repository (not always the same as the original author)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:129 +# unordered list +msgid "- Maintainers: Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:130 +# unordered list +msgid "- Contributors: Everyone who has contributed something back to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:131 +# unordered list +msgid "- Community members: People who use the project. They might be active in conversations or express their opinion on the project's direction." +msgstr "" + +#: open_research/02/opensourcesoftware.md:133 +msgid "Bigger projects may also have subcommittees or working groups focused on different tasks, such as tooling, triage, community moderation, and event organizing. Look on a project’s website for a “team” page, or in the repository for governance documentation, to find this information." +msgstr "" + +#: open_research/02/opensourcesoftware.md:135 +msgid "A great many open source projects are hosted on GitHub (see the chapter on version control for more detail), which has facilities such as:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:137 +# unordered list +msgid "- Issue tracker: Where people discuss issues related to the project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:138 +# unordered list +msgid "- Pull requests: Where people discuss and review changes that are in progress." +msgstr "" + +#: open_research/02/opensourcesoftware.md:139 +# unordered list +msgid "- Discussion forums or mailing lists: Some projects may use these channels for conversational topics (for example, \"How do I...\" or \"What do you think about...\" instead of bug reports or feature requests). Others use the issue tracker for all conversations." +msgstr "" + +#: open_research/02/opensourcesoftware.md:140 +# unordered list +msgid "- Synchronous chat channel: Some projects use chat channels (such as Slack or IRC) for casual conversation, collaboration, and quick exchanges." +msgstr "" + +#: open_research/02/opensourcesoftware.md:142 +# header +msgid "#### Contribute your changes" +msgstr "" + +#: open_research/02/opensourcesoftware.md:144 +msgid "Say you have added a feature or fixed a bug and want to contribute this work to the main project." +msgstr "" + +#: open_research/02/opensourcesoftware.md:146 +# ordered list +msgid "1. Read the documentation: The main project may have contributing guidelines or information in a readme instructing prospective contributors on how to supply their changes." +msgstr "" + +#: open_research/02/opensourcesoftware.md:147 +# ordered list +msgid "2. Make sure your conventions match those of the main project, both in style and structure: For example if all the variables in a project are named in some particular way yours should be too!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:148 +msgid "Consistent conventions make it much easier for someone who has not seen your piece of the project before to understand it rather than having to figure out your particular set of conventions *and* what the code is doing. The project's conventions may be outlined in its documentation, or may just be evident from inspection of the code itself." +msgstr "" + +#: open_research/02/opensourcesoftware.md:149 +# ordered list +msgid "3. Break your changes up into manageable, well-defined chunks: For example, if you have added two separate features don't submit them together. Keeping things \"clean\" in this way makes your work simpler to understand and review." +msgstr "" + +#: open_research/02/opensourcesoftware.md:150 +# ordered list +msgid "4. Test your changes: If the project comes with tests run them, and make sure you're testing against an up to date version of the project as it may have evolved considerably over time. Write specific tests for your changes and submit those too." +msgstr "" + +#: open_research/02/opensourcesoftware.md:151 +# ordered list +msgid "5. Do not just submit code, update relevant documentation too: If your changes are incorporated it will have to be updated, if you don not do it someone else will have to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:152 +# ordered list +msgid "6. Ask questions: If there are things you are unsure about there's no harm in asking. Many larger projects have dedicated forums or other venues for questions and discussion." +msgstr "" + +#: open_research/02/opensourcesoftware.md:153 +# ordered list +msgid "7. Be clear: When you submit your changes clearly describe the changes you have made, why you have made them, and how they have been implemented. This makes it as easier for someone looking at your work and deciding whether to incorporate it into the main project to do so. In the likely case the main project is hosted on GitHub you should put this in the pull request (see the version control chapter for more details)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:155 +# header +msgid "#### Looking for projects to contribute to and how to contribute to them" +msgstr "" + +#: open_research/02/opensourcesoftware.md:157 +msgid "You do not need to overthink what exactly your first contribution will be, or how it will look." +msgstr "" + +#: open_research/02/opensourcesoftware.md:158 +msgid "Instead, start by thinking about the projects you already use, or want to use." +msgstr "" + +#: open_research/02/opensourcesoftware.md:159 +msgid "The projects you will actively contribute to are the ones you find yourself coming back to." +msgstr "" + +#: open_research/02/opensourcesoftware.md:160 +msgid "Within those projects, whenever you catch yourself thinking that something could be better or different, act on your instinct. You might scan a readme and find a broken link or a typo." +msgstr "" + +#: open_research/02/opensourcesoftware.md:161 +msgid "Or you are a new user and you noticed something is broken, or an issue that you think should really be in the documentation. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:162 +msgid "Instead of ignoring it and moving on, or asking someone else to fix it, see whether you can help out by pitching in. That is what open source is all about!" +msgstr "" + +#: open_research/02/opensourcesoftware.md:164 +msgid "You can also use one of the following resources to help you discover and contribute to new projects:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:166 +# unordered list +msgid "- [Open Source Friday](https://opensourcefriday.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:167 +# unordered list +msgid "- [First Timers Only](https://www.firsttimersonly.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:168 +# unordered list +msgid "- [CodeTriage](https://www.codetriage.com/)" +msgstr "" + +#: open_research/02/opensourcesoftware.md:170 +msgid "If you are not sure how to start here is a few other ways you can go about it such as finding an open issue to tackle or asking if you can help write a new feature." +msgstr "" + +#: open_research/02/opensourcesoftware.md:172 +msgid "A common misconception about contributing to open source is that you need to contribute code. In fact, it is often the other parts of a project that are most neglected or overlooked. You will do the project a huge favour by offering to pitch in with these types of contributions! You could:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:174 +# unordered list +msgid "- Review code on other people's submissions." +msgstr "" + +#: open_research/02/opensourcesoftware.md:175 +# unordered list +msgid "- Write and improve the project's documentation." +msgstr "" + +#: open_research/02/opensourcesoftware.md:176 +# unordered list +msgid "- Curate a folder of examples showing how the project is used." +msgstr "" + +#: open_research/02/opensourcesoftware.md:177 +# unordered list +msgid "- Answer questions about the project on, for example, Stack Overflow," +msgstr "" + +#: open_research/02/opensourcesoftware.md:178 +# unordered list +msgid "- Keep things organized, for example, on GitHub by:" +msgstr "" + +#: open_research/02/opensourcesoftware.md:179 +# unordered list +msgid " - Linking to duplicate issues." +msgstr "" + +#: open_research/02/opensourcesoftware.md:180 +# unordered list +msgid " - Suggesting new issue labels." +msgstr "" + +#: open_research/02/opensourcesoftware.md:181 +# unordered list +msgid " - Going through open issues and suggesting closing old ones." +msgstr "" + +#: open_research/02/opensourcesoftware.md:182 +# unordered list +msgid " - Ask clarifying questions on recently opened issues to move the discussion forward." +msgstr "" + +#: open_research/02/opensourcesoftware.md:184 +# header +msgid "### Closed software" +msgstr "" + +#: open_research/02/opensourcesoftware.md:186 +msgid "What if you are working with people that do not use the open source model for their software?" +msgstr "" + +#: open_research/02/opensourcesoftware.md:187 +msgid "This may initially seem an affront to all the principles discussed so far, but there are usually very good reasons for why things are the way they are (for example legal, commercial, or security)." +msgstr "" + +#: open_research/02/opensourcesoftware.md:188 +msgid "Often, it will still be possible to use and contribute but the details of how might be different." +msgstr "" + +#: open_research/02/opensourcesoftware.md:189 +msgid "The kinds of practices used in 'closed' software are generally the same and the concepts and tools you can learn about in the Turing Way still apply." +msgstr "" + +#: open_research/02/opensourcesoftware.md:191 +msgid "Sometimes, however, there might not be good reasons for the closed source approach." +msgstr "" + +#: open_research/02/opensourcesoftware.md:192 +msgid "Different areas of research have different cultures which run against the grain of open principles and feel very frustrating. " +msgstr "" + +#: open_research/02/opensourcesoftware.md:193 +msgid "Tackling this barrier can be very tricky as cultures can take years or decades to change." +msgstr "" + +#: open_research/02/opensourcesoftware.md:195 +msgid "Working with closed software can offer both opportunities and threats to your research." +msgstr "" + +#: open_research/02/opensourcesoftware.md:196 +msgid "In all cases, understanding and respecting other's perspectives offers the greatest chances of success." +msgstr "" + +#: open_research/03/openhardware.md:1 +# header +msgid "## Open hardware" +msgstr "" + +#: open_research/03/openhardware.md:3 +msgid "\"Open hardware\", or \"open source hardware\", refers to the design specifications of a physical object that are licenced in such a way that said object can be studied, modified, created, and distributed by anyone." +msgstr "" + +#: open_research/03/openhardware.md:4 +msgid "Like open source software, the \"source code\" for open hardware - schematics, blueprints, logic designs, Computer Aided Design (CAD) drawings or files, and the like, is available for modification or enhancement by anyone." +msgstr "" + +#: open_research/03/openhardware.md:5 +msgid "Users with access to the tools that can read and manipulate these source files can update and improve the physical device and the code that underlies it, and, if they wish, proceed to share such modifications." +msgstr "" + +#: open_research/03/openhardware.md:7 +msgid "Open hardware's source code should be readily accessible, and its components are preferably easy for anyone to obtain. " +msgstr "" + +#: open_research/03/openhardware.md:8 +msgid "Essentially, open hardware eliminates common roadblocks to the design and manufacture of physical goods; it provides as many people as possible the ability to construct, remix, and share their knowledge of hardware design and function." +msgstr "" + +#: open_research/03/openhardware.md:10 +msgid "It is worth noting that open hardware does not necessary mean free. Units may still be sold (by the original designer or by others), but users *could* build them from scratch. Whether or not they choose to buy the unit, users can still get a full understanding of how the hardware works from open documentation, designs, and similar. " +msgstr "" + +#: open_research/03/openhardware.md:12 +# header +msgid "### Why open hardware?" +msgstr "" + +#: open_research/03/openhardware.md:14 +msgid "Open hardware allows researchers to understand exactly what their equipment is doing, how it is doing it, and to verify that it is doing it correctly, rather than having to extend a degree of trust." +msgstr "" + +#: open_research/03/openhardware.md:15 +msgid "Being aware of how the equipment that generates a result works puts researchers on a firmer footing in assessing those results." +msgstr "" + +#: open_research/03/openhardware.md:16 +msgid "Open hardware also makes research more reproducible as researchers looking to verify results can do the same thing." +msgstr "" + +#: open_research/03/openhardware.md:18 +msgid "Other benefits of open hardware include protection against lock-in." +msgstr "" + +#: open_research/03/openhardware.md:19 +msgid "Proprietary software for core infrastructure increases the risk of becoming locked in by the vendor or technology." +msgstr "" + +#: open_research/03/openhardware.md:20 +msgid "If this happens, researchers can be at the mercy of vendors' price increases and experience a lack of flexibility they can not easily and readily escape." +msgstr "" + +#: open_research/03/openhardware.md:21 +msgid "Further, if researchers want to modify their equipment to better suit their needs it is much easier to do so (and may only be legal) in the case of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:23 +# header +msgid "### Elements of an open source hardware project" +msgstr "" + +#: open_research/03/openhardware.md:25 +msgid "Here are some files that you should consider sharing when publishing your open source hardware project." +msgstr "" + +#: open_research/03/openhardware.md:26 +msgid "You are not required to post them all, but the more you share the more the community benefits." +msgstr "" + +#: open_research/03/openhardware.md:27 +msgid "There is a lot of crossover here with files to include in open source software projects." +msgstr "" + +#: open_research/03/openhardware.md:29 +# unordered list +msgid "- Overview / Introduction: Your open source hardware project should include a general description of the hardware's identity and purpose, written as much as possible for a general audience." +msgstr "" + +#: open_research/03/openhardware.md:30 +msgid "That is, explain what the project is and what it is for before you get into the technical details." +msgstr "" + +#: open_research/03/openhardware.md:31 +msgid "A good photo or rendering can help a lot here." +msgstr "" + +#: open_research/03/openhardware.md:32 +# unordered list +msgid "- A licence: This grants legal permission to anyone to re-use, modify, and distribute your designs and hardware according to the terms stated (for example, they must acknowledge your contribution). " +msgstr "" + +#: open_research/03/openhardware.md:33 +# unordered list +msgid "- Original design files: These are the original source files that you would use to make modifications to the hardware's design." +msgstr "" + +#: open_research/03/openhardware.md:34 +msgid "The act of sharing these files is the core practice of open source hardware." +msgstr "" + +#: open_research/03/openhardware.md:35 +# unordered list +msgid " - Ideally, your open source hardware project would be designed using a free and open source software application, to maximize the ability of others to view and edit it." +msgstr "" + +#: open_research/03/openhardware.md:36 +msgid " For better or worse however, hardware design files are often created in proprietary programs and stored in proprietary formats." +msgstr "" + +#: open_research/03/openhardware.md:37 +msgid " It is still essential to share these original design files; they constitute the original \"source code\" for the hardware." +msgstr "" + +#: open_research/03/openhardware.md:38 +msgid " They are the very files that someone will need in order to contribute changes to a given design." +msgstr "" + +#: open_research/03/openhardware.md:39 +# unordered list +msgid " - Try to make your design files easy for someone else to understand. In particular, organize them in a logical way, comment complex aspects, and note any unusual manufacturing procedures." +msgstr "" + +#: open_research/03/openhardware.md:40 +# unordered list +msgid " - Examples of Original Design Files include 2D drawings and computer-aided design (CAD) files." +msgstr "" + +#: open_research/03/openhardware.md:41 +# unordered list +msgid "- Auxiliary Design Files: Beyond the original design files, it is often helpful to share your design in additional, more accessible formats." +msgstr "" + +#: open_research/03/openhardware.md:42 +msgid "For example, best practice open sourcing a CAD design is to share the design not just in its native file format, but also in a range of interchange and export formats that can be opened or imported by other CAD programs." +msgstr "" + +#: open_research/03/openhardware.md:43 +# unordered list +msgid " - It is also helpful to provide ready-to-view outputs that can easily be viewed by end users who wish to understand (but not necessarily modify) the design." +msgstr "" + +#: open_research/03/openhardware.md:44 +msgid " For example, a PDF of a circuit board schematic." +msgstr "" + +#: open_research/03/openhardware.md:45 +msgid " These auxiliary design files allow people to study the design of the hardware, and sometimes even fabricate it, even without access to particular proprietary software packages." +msgstr "" + +#: open_research/03/openhardware.md:46 +msgid " However, note that auxiliary design files are never recommended as substitutes for original design files." +msgstr "" + +#: open_research/03/openhardware.md:47 +# unordered list +msgid "- Additional technical drawings: In their original formats, if required for fabrication of the device, in a commonly-readable format such as PDF." +msgstr "" + +#: open_research/03/openhardware.md:48 +# unordered list +msgid "- Bill Of Materials: While it might be possible to infer from the design files which parts make up a piece of hardware, it is important to provide a separate bill of materials." +msgstr "" + +#: open_research/03/openhardware.md:49 +msgid "This can be a spreadsheet (for example, CSV, XLS, Google Doc) or simply a text file with one part per line." +msgstr "" + +#: open_research/03/openhardware.md:50 +# unordered list +msgid " - Useful things to include in the bill of materials are part numbers, suppliers, costs, and a short description of each part." +msgstr "" + +#: open_research/03/openhardware.md:51 +msgid " Make it easy to tell which item in the bill of materials corresponds to which component in your design files: use matching reference designators in both places, provide a diagram indicating which part goes where, or otherwise explain the correspondence." +msgstr "" + +#: open_research/03/openhardware.md:52 +# unordered list +msgid "- Software and Firmware: You should share any code or firmware required to operate your hardware." +msgstr "" + +#: open_research/03/openhardware.md:53 +msgid "This will allow others to use it with their hardware or modify it along with their modifications to your hardware." +msgstr "" + +#: open_research/03/openhardware.md:54 +msgid "Document the process required to build your software, including links to any dependencies (for example, third-party libraries or tools). In addition, it is helpful to provide an overview of the state of the software (for example, \"stable\" or \"beta\" or \"barely-working hack\")." +msgstr "" + +#: open_research/03/openhardware.md:55 +# unordered list +msgid "- Photos: Photos help people understand what your project is and how to put it together." +msgstr "" + +#: open_research/03/openhardware.md:56 +msgid "It is good to publish photographs from multiple viewpoints and at various stages of assembly. If you do not have photos, posting 3D renderings of your design is a good alternative. Either way, it is good to provide captions or text that explain what is shown in each image and why it is useful." +msgstr "" + +#: open_research/03/openhardware.md:57 +# unordered list +msgid "- Instructions and Other Explanations: In addition to the design files themselves, there are a variety of explanations that are invaluable in helping others to make or modify your hardware:" +msgstr "" + +#: open_research/03/openhardware.md:58 +# unordered list +msgid " - Making the hardware: To help others make and modify your hardware design, you should provide instructions for going from your design files to the working physical hardware." +msgstr "" + +#: open_research/03/openhardware.md:59 +msgid " As part of the instructions, it is helpful to link to datasheets for the components / parts of your hardware and to list the tools required to assemble it." +msgstr "" + +#: open_research/03/openhardware.md:60 +msgid " If the design requires specialized tools, tell people where to get them." +msgstr "" + +#: open_research/03/openhardware.md:61 +# unordered list +msgid " - Using the hardware: Once someone has made the hardware, they need to know how to use it." +msgstr "" + +#: open_research/03/openhardware.md:62 +msgid " Provide instructions that explain what it does, how to set it up, and how to interact with it." +msgstr "" + +#: open_research/03/openhardware.md:63 +# unordered list +msgid " - Design rationale: If someone wants to modify your design, they will want to know why it is the way it is." +msgstr "" + +#: open_research/03/openhardware.md:64 +msgid " Explain the overall plan of the hardware's design and why you made the specific choices you did." +msgstr "" + +#: open_research/03/openhardware.md:65 +# unordered list +msgid " - Limit jargon: Keep in mind that these instructions may be read by someone whose expertise or training is different from yours." +msgstr "" + +#: open_research/03/openhardware.md:66 +msgid " As much as possible, try to write to a general audience, check your instructions for industry jargon, and be explicit about what you assume the user knows." +msgstr "" + +#: open_research/03/openhardware.md:67 +# unordered list +msgid " - Format: The instructions could be in a variety of formats, such as a wiki, text file, Google Doc, or PDF." +msgstr "" + +#: open_research/03/openhardware.md:68 +msgid " Remember, though, that others might want to modify your instructions as they modify your hardware design, so it is good to provide the original editable files for your documentation, not just output formats like PDF." +msgstr "" + +#: open_research/03/openhardware.md:70 +# header +msgid "### Open source hardware processes and practices" +msgstr "" + +#: open_research/03/openhardware.md:72 +# header +msgid "#### Designing your hardware" +msgstr "" + +#: open_research/03/openhardware.md:74 +msgid "If you are planning to open source a particular piece of hardware, following certain best practices in its design will make it easier for others to make and modify the hardware:" +msgstr "" + +#: open_research/03/openhardware.md:76 +# unordered list +msgid "- Use free and open source software design (CAD) tools where possible: If that is not feasible, try to use low-cost and/or widely-used software packages." +msgstr "" + +#: open_research/03/openhardware.md:77 +# unordered list +msgid "- Use standard and widely-available components, materials, and production processes: Try to avoid parts that are not available to individual customers or processes that require expensive setup costs." +msgstr "" + +#: open_research/03/openhardware.md:79 +# header +msgid "#### Hosting your design files" +msgstr "" + +#: open_research/03/openhardware.md:81 +msgid "A basic way of sharing your files is with a zip file on your website." +msgstr "" + +#: open_research/03/openhardware.md:82 +msgid "While this is a great start, it makes it difficult for others to follow your progress or to contribute improvements." +msgstr "" + +#: open_research/03/openhardware.md:83 +msgid "Using an online source-code repository (like GitHub, GitLab, or NotaBug) may be a better place to store your open source hardware projects." +msgstr "" + +#: open_research/03/openhardware.md:85 +# header +msgid "#### Distributing open source hardware" +msgstr "" + +#: open_research/03/openhardware.md:87 +# unordered list +msgid "- Provide links to the source (original design files) for your hardware on the product itself, its packaging, or its documentation." +msgstr "" + +#: open_research/03/openhardware.md:88 +# unordered list +msgid "- Make it easy to find the source (original design files) from the website for a product." +msgstr "" + +#: open_research/03/openhardware.md:89 +# unordered list +msgid "- Label the hardware with a version number or release date so that people can match the physical object with the corresponding version of its design files." +msgstr "" + +#: open_research/03/openhardware.md:90 +# unordered list +msgid "- In general, clearly indicate which parts of a product are open source (and which are not)." +msgstr "" + +#: open_research/04/openaccess.md:1 +# header +msgid "## Open access" +msgstr "" + +#: open_research/04/openaccess.md:3 +# header +msgid "### What is open access?" +msgstr "" + +#: open_research/04/openaccess.md:5 +msgid "One of the most common ways to disseminate research results is by writing a manuscript and publishing it in a journal, conference proceedings or book. For many years those publications were available to the public if purchased by means of a subscription fee or individually." +msgstr "" + +#: open_research/04/openaccess.md:6 +msgid "However, new knowledge is built by synthesizing current scholarship and then building upon it." +msgstr "" + +#: open_research/04/openaccess.md:7 +msgid "At the turn of the 21st century a new movement appeared with a clear objective: make all the research results available to anyone interested in reading it, free of charge by any user, with no technical obstacles such as mandatory registration or login to specific platforms." +msgstr "" + +#: open_research/04/openaccess.md:8 +msgid "This movement took the name of Open access and established two initial strategies to achieve its final goal: self-archiving and open access publishing." +msgstr "" + +#: open_research/04/openaccess.md:10 +# header +msgid "#### Repositories and self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:12 +msgid "The aim of the self-archiving movement is to provide tools and assistance to scholars to deposit their refereed journal articles in open electronic repositories." +msgstr "" + +#: open_research/04/openaccess.md:13 +msgid "As a result of the first strategy we see self-archiving practices: researchers depositing and disseminating papers in institutional or subject based repositories." +msgstr "" + +#: open_research/04/openaccess.md:14 +msgid "There has also been a growth in the publication of preprints through institutional repositories and preprint servers. " +msgstr "" + +#: open_research/04/openaccess.md:15 +msgid "Preprints are widely used in physical sciences and now emerging in life sciences and other fields." +msgstr "" + +#: open_research/04/openaccess.md:16 +msgid "Preprints are documents that have not been peer reviewed but are considered as a complete publication in a first stage." +msgstr "" + +#: open_research/04/openaccess.md:17 +msgid "Some of the preprint servers include open peer review services and the availability to post new versions of the initial paper once reviewed by peers." +msgstr "" + +#: open_research/04/openaccess.md:19 +msgid "At the beginning of 2019 more than 4000 repositories are available for researchers to self-archive their publications according to the [registry of open access repositories](http://roar.eprints.org/)." +msgstr "" + +#: open_research/04/openaccess.md:20 +msgid "In this list there are institutional repositories, subject based or thematic repositories, and harvesters." +msgstr "" + +#: open_research/04/openaccess.md:21 +msgid "Institutional repositories are generally managed by research performing institutions to provide to their community a place to archive and share openly papers and other research outputs." +msgstr "" + +#: open_research/04/openaccess.md:22 +msgid "Subject based repositories are usually managed by research communities and most of the contents are related to a certain discipline." +msgstr "" + +#: open_research/04/openaccess.md:23 +msgid "Finally, harvesters aggregate content from different repositories becoming sites to perform general searches and build other value-added services." +msgstr "" + +#: open_research/04/openaccess.md:25 +msgid "When choosing a journal to publish research results, researchers should take a moment to read the journal policy regarding the transfer of copyright." +msgstr "" + +#: open_research/04/openaccess.md:26 +msgid "Many journals still require for publication that authors transfer full copyright." +msgstr "" + +#: open_research/04/openaccess.md:27 +msgid "This transfer of rights implies that authors must ask for permission to reuse their own work beyond what is allowed by the applicable law, unless there are some uses already granted." +msgstr "" + +#: open_research/04/openaccess.md:28 +msgid "Such granted uses may include teaching purposes, sharing with colleagues, and self-archiving by researchers of their papers in repositories." +msgstr "" + +#: open_research/04/openaccess.md:29 +msgid "Sometimes there a common policy among all the journals published by the same publishers but in general journals have their own policy, especially when they are published on behalf of a scientific society." +msgstr "" + +#: open_research/04/openaccess.md:30 +msgid "When looking at the self-archiving conditions we must identify two key issues: the version of the paper that can be deposited and when it can be made publicly available." +msgstr "" + +#: open_research/04/openaccess.md:32 +msgid "Regarding the version, some journals allow the dissemination of the submitted version, also known as a preprint, and they allow its replacement for a reviewed version once the final paper has been published." +msgstr "" + +#: open_research/04/openaccess.md:33 +msgid "Due to the increase of policies requiring access to research results, most of the journals allow self-archiving of the accepted version of the paper, also known as the author manuscript or postprint." +msgstr "" + +#: open_research/04/openaccess.md:34 +msgid "This version is the final text once the peer review process has ended but it has not the final layout of the publication. " +msgstr "" + +#: open_research/04/openaccess.md:35 +msgid "Finally some journals do allow researchers to deposit the final published version, also known as the version of record." +msgstr "" + +#: open_research/04/openaccess.md:37 +msgid "In relation to the moment to make the paper publicly available, many journals establish a period of time from its original publication - the embargo period, which can range from zero to 60 months - when making the paper publicly available is not permitted." +msgstr "" + +#: open_research/04/openaccess.md:38 +msgid "Some journals include or exclude embargoes depending on the versions." +msgstr "" + +#: open_research/04/openaccess.md:39 +msgid "For instance the accepted version could be made publicly available after publication but the published version must wait 12 months." +msgstr "" + +#: open_research/04/openaccess.md:41 +# header +msgid "#### Open access publishing" +msgstr "" + +#: open_research/04/openaccess.md:43 +msgid "Open access publishing attempts to ensure permanent open access to all the articles published in journals, and as a result we have seen the creation of the open access journals." +msgstr "" + +#: open_research/04/openaccess.md:44 +msgid "The number of open access journals has increased during the last years, according to the Directory of Open access Journals \\([DOAJ](http://www.doaj.org)\\), currently there are more than 12,000." +msgstr "" + +#: open_research/04/openaccess.md:45 +msgid "Open access journal must provide free access to its contents but it also must licence them to allow reusability." +msgstr "" + +#: open_research/04/openaccess.md:47 +msgid "Currently many paywalled journals offer individual open access options to researchers once the paper is accepted after peer review." +msgstr "" + +#: open_research/04/openaccess.md:48 +msgid "Those options include the publication under a free content licence and free accessibility to anyone since its first publication." +msgstr "" + +#: open_research/04/openaccess.md:49 +msgid "This model is commonly known as the hybrid model because in the same issue of a journal, readers can find open access and paywalled contributions." +msgstr "" + +#: open_research/04/openaccess.md:50 +msgid "Usually publishers ask for a fee to open individual contributions." +msgstr "" + +#: open_research/04/openaccess.md:52 +msgid "Open access publishing has two primary versions — gratis and libre." +msgstr "" + +#: open_research/04/openaccess.md:53 +msgid "Gratis open access is simply making research available for others to read without having to pay for it." +msgstr "" + +#: open_research/04/openaccess.md:54 +msgid "However, it does not grant the user the right to make copies, distribute, or modify the work in any way beyond fair use." +msgstr "" + +#: open_research/04/openaccess.md:55 +msgid "Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users additional rights, usually via a Creative Commons licence, so that people are free to reuse and remix the research." +msgstr "" + +#: open_research/04/openaccess.md:56 +msgid "There are varying degrees of what may be considered libre open access." +msgstr "" + +#: open_research/04/openaccess.md:57 +msgid "For example, some scholarly articles may permit all uses except commercial use, some may permit all uses except derivative works, and some may permit all uses and simply require attribution." +msgstr "" + +#: open_research/04/openaccess.md:58 +msgid "While some would argue that libre open access should be free of any copyright restrictions (except attribution), other scholars consider a work that removes at least some permission barriers to be libre." +msgstr "" + +#: open_research/04/openaccess.md:60 +# header +msgid "### Why does open access matter?" +msgstr "" + +#: open_research/04/openaccess.md:62 +msgid "Research is useless if it’s not shared; even the best research is ineffectual if others aren’t able to read and build on it. " +msgstr "" + +#: open_research/04/openaccess.md:63 +msgid "When price barriers keep articles locked away, research cannot achieve its full potential." +msgstr "" + +#: open_research/04/openaccess.md:64 +msgid "Open access benefits researchers who can work more effectively with a better understanding of the literature." +msgstr "" + +#: open_research/04/openaccess.md:65 +msgid "It also helps avoid duplication of effort." +msgstr "" + +#: open_research/04/openaccess.md:66 +msgid "No researcher (or funder) wants to waste time and money conducting a study if they know it has been attempted elsewhere." +msgstr "" + +#: open_research/04/openaccess.md:67 +msgid "But, duplication of effort is all-too-possible when researchers can’t effectively communicate with one another and make results known to others in their field and beyond." +msgstr "" + +#: open_research/04/openaccess.md:68 +msgid "It also benefits researchers by providing better visibility and therefore higher impact/citation rate for their scholarship. " +msgstr "" + +#: open_research/04/openaccess.md:69 +msgid "Numerous publishers, both non-profit and for-profit, voluntarily make their articles openly available at the time of publication or within 6-12 months." +msgstr "" + +#: open_research/04/openaccess.md:70 +msgid "Many have switched from a closed, subscription model to an open one as a strategic business decision to increase their journal's exposure and impact." +msgstr "" + +#: open_research/04/openaccess.md:71 +msgid "Further it can be argued that taxpayers who pay for much of the research published in journals have a right to access the information resulting from that investment without charge." +msgstr "" + +#: open_research/04/openaccess.md:72 +msgid "Finally, if research is available to the widest possible pool of readers then it is more likely/easy for it to be checked and reproduced. " +msgstr "" + +#: open_research/04/openaccess.md:74 +# header +msgid "### Best practice for open access" +msgstr "" + +#: open_research/04/openaccess.md:76 +# header +msgid "#### Self-archiving" +msgstr "" + +#: open_research/04/openaccess.md:78 +msgid "Self-archive a publication in a suitable repository, institutional or subject-based, following the possible restrictions posed by the publisher, for example an embargo period, or limits on the allowed version to be deposited in such archives." +msgstr "" + +#: open_research/04/openaccess.md:79 +msgid "In doing this it is important to make sure you are aware of the copyright implications of any documents/agreements you make when submitting your manuscript to a journal." +msgstr "" + +#: open_research/04/openaccess.md:80 +msgid "If your institution does not have an institutional repository, advocate for the creation of one." +msgstr "" + +#: open_research/04/openaccess.md:82 +# header +msgid "#### Publication" +msgstr "" + +#: open_research/04/openaccess.md:84 +msgid "Consider submitting your work to a journal that is open access." +msgstr "" + +#: open_research/04/openaccess.md:85 +msgid "When doing this be aware that there may be funds or discounts available to cover any associated costs." +msgstr "" + +#: open_research/05/opennotebooks.md:1 +# header +msgid "## Open notebooks" +msgstr "" + +#: open_research/05/opennotebooks.md:3 +msgid "Electronic Lab Notebooks (ELNs) enable researchers to organize and store experimental procedures, protocols, plans, notes, data, and even unfiltered interpretations using their computer or mobile device." +msgstr "" + +#: open_research/05/opennotebooks.md:4 +msgid "They are a digital analogue to the paper notebook most researchers keep." +msgstr "" + +#: open_research/05/opennotebooks.md:5 +msgid "ELNs can offer several advantages over the traditional paper notebook in documenting research during the active phase of a project, including searchability within and across notebooks, secure storage with multiple redundancies, remote access to notebooks, and the ability to easily share notebooks among team members and collaborators." +msgstr "" + +#: open_research/05/opennotebooks.md:7 +msgid "Open notebook research is simply the practice of making such notebooks openly available, usually online." +msgstr "" + +#: open_research/05/opennotebooks.md:8 +msgid "Some researchers choose to keep their notebooks open from the very beginning of their projects." +msgstr "" + +#: open_research/05/opennotebooks.md:9 +msgid "Rather than wait months, even years, to share their research through journal publication as is the current practice, this allows researchers to post their experimental data and protocols online and in real-time." +msgstr "" + +#: open_research/05/opennotebooks.md:10 +msgid "Sharing research in this open and timely manner helps to reduce duplication of work, helps foster new collaborations, and cultivates a more open dialogue with others." +msgstr "" + +#: open_research/05/opennotebooks.md:11 +msgid "It also helps researchers avoid making exploring dead ends and making mistakes that have already been covered by their colleague, but went unpublished because of lack of scientific interest." +msgstr "" + +#: open_research/05/opennotebooks.md:13 +msgid "Open notebooks have the further benefit of increasing the quality of scientific outputs by forcing researchers to be careful, thorough, and explicit." +msgstr "" + +#: open_research/05/opennotebooks.md:14 +msgid "Making research open has the added benefit of increasing the likelihood that any errors made in an investigation will be spotted quickly, instead of down the line." +msgstr "" + +#: open_research/05/opennotebooks.md:15 +msgid "Immediate fixes will have much less impact on a research project, which will save a research time, the lab money, and pride." +msgstr "" + +#: open_research/05/opennotebooks.md:17 +msgid "Ideally, every scientist would maintain an open notebook in real-time which would encompass all aspects of their research." +msgstr "" + +#: open_research/05/opennotebooks.md:18 +msgid "But many fears about dealing with complete open access, conflicts with intellectual property and publications, and online data overload hamper this movement." +msgstr "" + +#: open_research/05/opennotebooks.md:19 +msgid "To combat this, practitioners encourage any form of open notebook research, \"make open what you can\", even if that means uploading some information for a project from many years ago that never saw the light of day." +msgstr "" + +#: open_research/06/openscholarship.md:1 +# header +msgid "## Open scholarship" +msgstr "" + +#: open_research/06/openscholarship.md:3 +msgid "Open research and its subcomponents fit under the umbrella of a broader concept - open scholarship." +msgstr "" + +#: open_research/06/openscholarship.md:5 +msgid "![open_umbrella](../../figures/open_umbrella.png)" +msgstr "" + +#: open_research/06/openscholarship.md:7 +# header +msgid "### Open educational resources" +msgstr "" + +#: open_research/06/openscholarship.md:9 +msgid "Open educational resources (OERs) are teaching and learning materials that can be freely used and reused for learning and/or teaching at no cost, and without needing to ask permission. Examples are courses, including Massive Online Open Courses (MOOCs), lectures, teaching materials, assignments, and various other resources. OERs are available in many different formats compatible with online usage, most obviously text, images, audio, and video. Anyone with internet access can access and use OERs; access is not dependent on location or membership of a particular institution." +msgstr "" + +#: open_research/06/openscholarship.md:11 +msgid "Unlike copyrighted resources, OERs have been authored or created by an individual or organization that chooses to retain few, if any, ownership rights. In some cases, that means anyone can download a resource and share it with colleagues and students. In other cases, this may go further and enable people to edit resources and then re-post them as a remixed work. How do you know your options? OERs often have a Creative Commons licence or other permission to let you know how the material may be used, reused, adapted, and shared." +msgstr "" + +#: open_research/06/openscholarship.md:13 +msgid "Fully open OERs comply with the 5 Rs:" +msgstr "" + +#: open_research/06/openscholarship.md:15 +# unordered list +msgid "- Retain: the right to make, own, and control copies of the content." +msgstr "" + +#: open_research/06/openscholarship.md:16 +# unordered list +msgid "- Reuse: the right to use the content in a wide range of ways (for example, in a class, in a study group, on a website, in a video)." +msgstr "" + +#: open_research/06/openscholarship.md:17 +# unordered list +msgid "- Revise: the right to adapt, adjust, modify, or alter the content itself (for example, translate the content into another language)." +msgstr "" + +#: open_research/06/openscholarship.md:18 +# unordered list +msgid "- Remix: the right to combine the original or revised content with other open content to create something new (for example, incorporate the content into a mashup)." +msgstr "" + +#: open_research/06/openscholarship.md:19 +# unordered list +msgid "- Redistribute: the right to share copies of the original content, your revisions, or your remixes with others (for example, give a copy of the content to a friend)." +msgstr "" + +#: open_research/06/openscholarship.md:21 +msgid "Researchers generate a great deal of educational resources in the course of teaching students and each other (at workshops, for example)." +msgstr "" + +#: open_research/06/openscholarship.md:22 +msgid "By making these openly available, for example in the [open educational resource commons](https://www.oercommons.org/), the wider community can benefit from them in three main ways:" +msgstr "" + +#: open_research/06/openscholarship.md:24 +# ordered list +msgid "1. Most obviously, the community can use the materials to learn about the material they cover." +msgstr "" + +#: open_research/06/openscholarship.md:25 +# ordered list +msgid "2. Sharing resources reduces duplication of effort." +msgstr "" + +#: open_research/06/openscholarship.md:26 +msgid "If an educator needs materials for teaching and such materials already exist openly then they need not make their own from scratch, saving time." +msgstr "" + +#: open_research/06/openscholarship.md:27 +# ordered list +msgid "3. Making materials openly available helps a community build better resources by improving resources that already exist and combining OERs to take advantage of their different strengths, such as a great diagram or explanation." +msgstr "" + +#: open_research/06/openscholarship.md:29 +msgid "Beyond the raw practical benefits the worldwide OER movement is rooted in the human right to access high-quality education. " +msgstr "" + +#: open_research/06/openscholarship.md:30 +msgid "This shift in educational practice is about participation and co-creation." +msgstr "" + +#: open_research/06/openscholarship.md:31 +msgid "Open Educational Resources (OERs) offer opportunities for systemic change in teaching and learning content through engaging educators in new participatory processes and effective technologies for engaging with learning." +msgstr "" + +#: open_research/06/openscholarship.md:33 +# header +msgid "### Equity, diversity, inclusion" +msgstr "" + +#: open_research/06/openscholarship.md:35 +msgid "Open scholarship means open to *everyone* without discrimination based on factors such as race, gender, sexual orientation, or any number of other factors." +msgstr "" + +#: open_research/06/openscholarship.md:36 +msgid "As a community we should undertake to ensure equitable opportunities for all." +msgstr "" + +#: open_research/06/openscholarship.md:37 +msgid "We can go about that by deliberately fostering welcoming, inclusive cultures within out communities." +msgstr "" + +#: open_research/06/openscholarship.md:38 +msgid "For example, reasonable accommodations should be made wherever possible to include community members with disabilities to enable them to participate fully, and this can be as simple as choosing colourblind-safe colour schemes when making graphs." +msgstr "" + +#: open_research/06/openscholarship.md:40 +# header +msgid "### Citizen science" +msgstr "" + +#: open_research/06/openscholarship.md:42 +msgid "Citizen science is the involvement of the public in scientific research – whether community-driven research or global investigations, the Oxford English Dictionary recently defined it as: \"scientific work undertaken by members of the general public, often in collaboration with or under the direction of professional scientists and scientific institutions\"." +msgstr "" + +#: open_research/06/openscholarship.md:43 +msgid "Citizen science offers the power of science to everyone, and the power of everyone to science." +msgstr "" + +#: open_research/06/openscholarship.md:45 +msgid "By allowing members of the public to contribute to scientific research, citizen science helps engage and invest the wider world in science." +msgstr "" + +#: open_research/06/openscholarship.md:46 +msgid "It also benefits researchers by offering manpower that simply would not be accessible otherwise." +msgstr "" + +#: open_research/06/openscholarship.md:47 +msgid "Examples of this include [finding](https://citizensciencegames.com/games/eterna/) ways of folding molecules, and [classifying](https://www.zooniverse.org/) different types of galaxies." +msgstr "" + +#: open_research/06/openscholarship.md:49 +# header +msgid "### Patient and Public Involvement" +msgstr "" + +#: open_research/06/openscholarship.md:50 +msgid "Whilst citizen science encompasses one way of contributing to scientific research, Patient and Public Involvement (PPI) is a far more specialised form of citizen science which is particularly useful when doing research on health and/or social issues." +msgstr "" + +#: open_research/06/openscholarship.md:52 +msgid "PPI is *not*:" +msgstr "" + +#: open_research/06/openscholarship.md:53 +# unordered list +msgid "- Participation: Recruitment of participants (such as for a clinical trial or survey) to contribute data to a project." +msgstr "" + +#: open_research/06/openscholarship.md:54 +# unordered list +msgid "- Engagement: Dissemination, such as presenting at patient interest groups or writing a blog post." +msgstr "" + +#: open_research/06/openscholarship.md:56 +msgid "PPI *is*:" +msgstr "" + +#: open_research/06/openscholarship.md:57 +# unordered list +msgid "- Involvement: patients and members of the public contribute at *all* stages of the research cycle." +msgstr "" + +#: open_research/06/openscholarship.md:59 +msgid "When incorporating PPI into research, researchers work *with* volunteers, rather than doing work *about* them." +msgstr "" + +#: open_research/06/openscholarship.md:60 +msgid "PPI volunteers are usually patients or members of the public with a particular interest in some area of research which means that the topic is often very personal, and being involved in the research cycle can be an empowering experience." +msgstr "" + +#: open_research/06/openscholarship.md:61 +msgid "For the researcher, PPI often generates unique and invaluable insights from the volunteers' own personal expertise which cannot always be predicted by the researchers themselves." +msgstr "" + +#: open_research/06/openscholarship.md:63 +msgid "It is a good idea to consider PPI very early in a project, ideally before any grant applications or submissions for ethical approval have been written." +msgstr "" + +#: open_research/06/openscholarship.md:64 +msgid "PPI volunteers can help researchers in many ways, such as the following:" +msgstr "" + +#: open_research/06/openscholarship.md:65 +# ordered list +msgid "1. Generate or shape research questions." +msgstr "" + +#: open_research/06/openscholarship.md:66 +# ordered list +msgid "2. Contribute to, or review, study design." +msgstr "" + +#: open_research/06/openscholarship.md:67 +# ordered list +msgid "3. Help with grant applications or submissions to research ethics committees (particularly the lay summary)." +msgstr "" + +#: open_research/06/openscholarship.md:68 +# ordered list +msgid "4. Collect data." +msgstr "" + +#: open_research/06/openscholarship.md:69 +# ordered list +msgid "5. Analyse data." +msgstr "" + +#: open_research/06/openscholarship.md:70 +# ordered list +msgid "6. Contribute to the manuscript and be listed as a co-author." +msgstr "" + +#: open_research/06/openscholarship.md:71 +# ordered list +msgid "7. Disseminate findings in plain English." +msgstr "" + +#: open_research/06/openscholarship.md:73 +msgid "One of the biggest barriers to PPI is not knowing how to get started." +msgstr "" + +#: open_research/06/openscholarship.md:74 +msgid "The UK National Institute for Health Research have their own site, [INVOLVE](https://www.invo.org.uk/), to help familiarise yourself with the foundations of PPI." +msgstr "" + +#: open_research/06/openscholarship.md:75 +msgid "Additionally, charities related to your specific research field may be able to facilitate or support PPI; for example [Cancer Research UK](https://www.cancerresearchuk.org/funding-for-researchers/patient-involvement-toolkit-for-researchers) and [Parkinson's UK](https://www.parkinsons.org.uk/research/patient-and-public-involvement-ppi) have formal guides in place that provide a comprehensive overview of PPI." +msgstr "" + +#: open_research/07/resources.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: open_research/07/resources.md:3 +# header +msgid "### Open data" +msgstr "" + +#: open_research/07/resources.md:5 +# unordered list +msgid "- [ ] Ensure your data is in a simple, standard format or formats which is machine and human readable." +msgstr "" + +#: open_research/07/resources.md:6 +# unordered list +msgid "- [ ] Check, reformat or create metadata to clearly describe what the data is, how it was collected, and any associated strengths/weaknesses to someone that finds it." +msgstr "" + +#: open_research/07/resources.md:7 +# unordered list +msgid "- [ ] Identify a relevant, easily discoverable repository or repositories to host your data, and upload it there." +msgstr "" + +#: open_research/07/resources.md:8 +# unordered list +msgid "- [ ] Assign your data a persistent identifier such as a DOI." +msgstr "" + +#: open_research/07/resources.md:10 +# header +msgid "### Open source software" +msgstr "" + +#: open_research/07/resources.md:12 +# unordered list +msgid "- [ ] Put your code in a freely accessible repository." +msgstr "" + +#: open_research/07/resources.md:13 +#: open_research/07/resources.md:21 +# unordered list +msgid "- [ ] Include a licence granting others the right to use, copy and modify your work. You can use [this](https://choosealicense.com/) website to help you pick the most appropriate licence for your project." +msgstr "" + +#: open_research/07/resources.md:14 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project such as what it is, how to use/install it and how to run any tests." +msgstr "" + +#: open_research/07/resources.md:15 +# unordered list +msgid "- [ ] If you want others to collaborate on the project include contribution guidelines." +msgstr "" + +#: open_research/07/resources.md:17 +# header +msgid "### Open hardware" +msgstr "" + +#: open_research/07/resources.md:19 +# unordered list +msgid "- [ ] Use open hardware where practical." +msgstr "" + +#: open_research/07/resources.md:20 +# unordered list +msgid "- [ ] Make detailed documentation and designs for any hardware you develop openly available." +msgstr "" + +#: open_research/07/resources.md:22 +# unordered list +msgid "- [ ] Include a readme file containing useful information about a project (for example, what it is and the materials used)." +msgstr "" + +#: open_research/07/resources.md:24 +# header +msgid "### Open access" +msgstr "" + +#: open_research/07/resources.md:26 +# unordered list +msgid "- [ ] Publish your research in an open access journal." +msgstr "" + +#: open_research/07/resources.md:27 +# unordered list +msgid "- [ ] Store a copy and/or preprint of your work in a freely accessible public repository." +msgstr "" + +#: open_research/07/resources.md:29 +# header +msgid "### Open notebooks" +msgstr "" + +#: open_research/07/resources.md:31 +# unordered list +msgid "- [ ] Keep notes in an Electronic Lab Notebook." +msgstr "" + +#: open_research/07/resources.md:32 +# unordered list +msgid "- [ ] Make your notebooks publicly accessible online." +msgstr "" + +#: open_research/07/resources.md:34 +# header +msgid "## What to learn next" +msgstr "" + +#: open_research/07/resources.md:36 +msgid "If you haven't had a chance already, take a look at the chapter on [version control](/version_control/version_control), particularly the sections on GitHub in the latter half." +msgstr "" + +#: open_research/07/resources.md:38 +# header +msgid "## Further reading" +msgstr "" + +#: open_research/07/resources.md:40 +msgid "[This](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/) book on open science has a great deal of interesting information." +msgstr "" + +#: open_research/07/resources.md:41 +msgid "For information specific to open source software [this](https://opensource.guide/) is a good place to look." +msgstr "" + +#: open_research/07/resources.md:42 +msgid "For more information on DOIs and citing resources look [here](http://www.doi.org/index.html)." +msgstr "" + +#: open_research/07/resources.md:43 +msgid "If you want to take a look at an active open source project this textbook *is* one." +msgstr "" + +#: open_research/07/resources.md:44 +msgid "The source can be found on GitHub [here](https://github.com/alan-turing-institute/the-turing-way) and for further details related to this project you can take a look at the project [website](https://www.turing.ac.uk/research/research-projects/turing-way-handbook-reproducible-data-science)." +msgstr "" + +#: open_research/07/resources.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: open_research/07/resources.md:48 +# unordered list +msgid "- **Citizen science:** The involvement of members of the public in scientific research." +msgstr "" + +#: open_research/07/resources.md:49 +# unordered list +msgid "- **Contributing guidelines:** Guidelines outlining how a person should go about contributing to an open source project." +msgstr "" + +#: open_research/07/resources.md:50 +# unordered list +msgid "- **Contributor:** Someone that has contributed something (not necessarily code) to an open source project." +msgstr "" + +#: open_research/07/resources.md:51 +# unordered list +msgid "- **DOI:** A widely used type of persistent identifier." +msgstr "" + +#: open_research/07/resources.md:52 +# unordered list +msgid "- **GitHub:** An online code hosting and version control service. It has a great many features to aid collaboration between users, and hosts a large number of open source projects." +msgstr "" + +#: open_research/07/resources.md:53 +# unordered list +msgid "- **Maintainer:** Contributors who are responsible for driving the vision and managing the organizational aspects of the project. They may also be authors and/or owners of the project." +msgstr "" + +#: open_research/07/resources.md:54 +# unordered list +msgid "- **Metadata:** Data used to describe other data. For example (35, 33, 27, 30, 33) is data but the units (miles per hour) and the fact these are the speeds of cars on a certain stretch of road is metadata." +msgstr "" + +#: open_research/07/resources.md:55 +# unordered list +msgid "- **Open access publishing (gratis):** The practice of making research publications available to anyone to read without charge." +msgstr "" + +#: open_research/07/resources.md:56 +# unordered list +msgid "- **Open access publishing (libre):** Libre open access is gratis, meaning the research is available free of charge, but it goes further by granting users the right to copy, reuse, and remix the publication." +msgstr "" + +#: open_research/07/resources.md:57 +# unordered list +msgid "- **Open data:** Data that is freely available online for reuse without bureaucratic or administrative barriers." +msgstr "" + +#: open_research/07/resources.md:58 +# unordered list +msgid "- **Open educational resource:** Educational materials available online for anybody to use, remix and distribute." +msgstr "" + +#: open_research/07/resources.md:59 +# unordered list +msgid "- **Open notebook:** The practise of making research notebooks openly available." +msgstr "" + +#: open_research/07/resources.md:60 +# unordered list +msgid "- **Open source software:** Software which is available online for anybody to view, use, modify, and distribute." +msgstr "" + +#: open_research/07/resources.md:61 +# unordered list +msgid "- **Open source hardware:** Hardware with documentation, designs, materials used, and other relevant information freely accessible and available" +msgstr "" + +#: open_research/07/resources.md:62 +# unordered list +msgid "- **Persistent identifier:** A long-lived method for identifying a resource that is unique, and widely understandable by a community." +msgstr "" + +#: open_research/07/resources.md:63 +# unordered list +msgid "- **Readme:** A file which contains useful information about a project such as what it is, how to use/install it, how to test it, and how to contribute to it." +msgstr "" + +#: open_research/07/resources.md:64 +# unordered list +msgid "- **Repository:** A long-lived place on the internet where resources (be they data, software, publications or anything else) can be stored and accessed." +msgstr "" + +#: open_research/07/resources.md:65 +# unordered list +msgid "- **Self-archive:** To place your research output in a repository." +msgstr "" + +#: open_research/07/resources.md:67 +# header +msgid "## Bibliography" +msgstr "" + +#: open_research/07/resources.md:68 +# unordered list +msgid "- [1.](https://www.fosteropenscience.eu/content/what-open-science-introduction) **CC-BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:69 +# unordered list +msgid "- [2.](https://open-science-training-handbook.gitbook.io/book/introduction) **CC 1.0**" +msgstr "" + +#: open_research/07/resources.md:70 +# unordered list +msgid "- [3.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:71 +# unordered list +msgid "- [4.](https://link.springer.com/chapter/10.1007/978-3-319-00026-8_2) **Creative Commons Attribution Noncommercial Licence**" +msgstr "" + +#: open_research/07/resources.md:72 +# unordered list +msgid "- [5.](https://elifesciences.org/articles/16800) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:73 +# unordered list +msgid "- [6.](https://www.fosteropenscience.eu/content/introduction-open-science-funders-introductory) **Attribution + Noncommercial - CC-BY-NC**" +msgstr "" + +#: open_research/07/resources.md:74 +# unordered list +msgid "- [7.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/vision/open_research_data.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:75 +# unordered list +msgid "- [8.](http://opendatahandbook.org/guide/en/what-is-open-data/) **CC Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:76 +# unordered list +msgid "- [9.](https://opendatacharter.net/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:77 +# unordered list +msgid "- [10.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/making_data_citeable.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:78 +# unordered list +msgid "- [11.](http://book.openingscience.org.s3-website-eu-west-1.amazonaws.com/cases_recipes_howtos/challenges_of_open_data_in_medical_research.html) **Creative Commons Attribution-NonCommercical**" +msgstr "" + +#: open_research/07/resources.md:79 +# unordered list +msgid "- [12.](http://www.dcc.ac.uk/resources/how-guides/cite-datasets) **Creative Commons**" +msgstr "" + +#: open_research/07/resources.md:80 +# unordered list +msgid "- [13.](https://www.open-contracting.org/2016/09/19/diving-deeper-commercial-confidentiality/) **Creative Commons Attribution 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:81 +# unordered list +msgid "- [14.](https://ben.balter.com/2015/11/23/why-open-source/) **CC BY 3.0**" +msgstr "" + +#: open_research/07/resources.md:82 +# unordered list +msgid "- [15.](https://opensource.guide/starting-a-project/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:83 +# unordered list +msgid "- [16.](https://opensource.guide/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:84 +# unordered list +msgid "- [17.](https://opensource.com/resources/what-open-access) **Attribution-ShareAlike 4.0 International**" +msgstr "" + +#: open_research/07/resources.md:85 +# unordered list +msgid "- [18.](http://www.righttoresearch.org/learn/whyOA/index.shtml) **Creative Commons Attribution 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:86 +# unordered list +msgid "- [19.](https://open-science-training-handbook.gitbook.io/book/open-science-basics/open-access-to-published-research-results) **CC0 1.0 Universal**" +msgstr "" + +#: open_research/07/resources.md:87 +# unordered list +msgid "- [20.](https://www.oercommons.org/about) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Licence**" +msgstr "" + +#: open_research/07/resources.md:88 +# unordered list +msgid "- [21.](https://libguides.ioe.ac.uk/oer) **Creative CommonsAttribution-NonCommercial-ShareAlike 2.0 UK: England & Wales (CC BY-NC-SA 2.0 UK)**" +msgstr "" + +#: open_research/07/resources.md:89 +# unordered list +msgid "- [22.](https://opencontent.org/blog/archives/3221) **Creative Commons Attribution licence version 4.0**" +msgstr "" + +#: open_research/07/resources.md:90 +# unordered list +msgid "- [23.](https://opensource.com/resources/what-open-hardware) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:91 +# unordered list +msgid "- [24.](https://opensource.com/article/17/8/enterprise-open-source-advantages) **CC BY-SA 4.0**" +msgstr "" + +#: open_research/07/resources.md:92 +# unordered list +msgid "- [25.](https://www.oshwa.org/sharing-best-practices/) **Creative Commons Attribution-ShareAlike 4.0 International Licence**" +msgstr "" + +#: open_research/07/resources.md:93 +# unordered list +msgid "- [26.](https://openlabnotebooks.org/open-science-at-sgc/) **CC BY 4.0**" +msgstr "" + +#: open_research/07/resources.md:94 +# unordered list +msgid "- [27.](http://onsnetwork.org/) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: open_research/07/resources.md:95 +# unordered list +msgid "- [28.](https://libraries.mit.edu/data-management/store/electronic-lab-notebooks/) **CC BY-NC 2.0**" +msgstr "" + +#: open_research/07/resources.md:96 +# unordered list +msgid "- [29.](https://www.citizenscience.org/) **(CC BY 4.0)**" +msgstr "" + +#: open_research/07/resources.md:98 +# header +msgid "## Footnotes" +msgstr "" + +#: open_research/07/resources.md:100 +# ordered list +msgid "1. References by discipline: Agricultural studies (Kousha and Abdoli, 2010); Physics/astronomy (Gentil-Beccot et al., 2010; Harnad and Brody, 2004; Metcalfe, 2006); Medicine (Sahu et al., 2005; Xu et al., 2011); Computer science (Lawrence, 2001); Sociology/social sciences (Hajjem et al., 2006; Norris et al., 2008; Xu et al., 2011); Psychology (Hajjem et al., 2006); Political science (Hajjem et al., 2006; Antelman, 2004; Atchison and Bull, 2015); Management (Hajjem et al., 2006); Law (Donovan et al., 2015; Hajjem et al., 2006); Economics (Hajjem et al., 2006; McCabe and Snyder, 2015; Norris et al., 2008; Wohlrabe, 2014); Mathematics (Antelman, 2004; Davis and Fromerth, 2007; Norris et al., 2008); Health (Hajjem et al., 2006); Engineering (Antelman, 2004; Koler-Povh et al., 2014); Philosophy (Antelman, 2004); Education (Hajjem et al., 2006; Zawacki-Richter et al., 2010); Business (Hajjem et al., 2006; McCabe and Snyder, 2015); Communication studies (Zhang, 2006); Ecology (McCabe and Snyder, 2014; Norris et al., 2008); Biology (Frandsen, 2009b; Hajjem et al., 2006; McCabe and Snyder, 2014)." +msgstr "" + +#: open_research/open_research.md:1 +# header +msgid "# Open research" +msgstr "" + +#: open_research/open_research.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: open_research/open_research.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: open_research/open_research.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: open_research/open_research.md:7 +msgid "| [Experience with version control](/version_control/version_control) | Helpful | Experience with GitHub is particularly useful |" +msgstr "" + +#: open_research/open_research.md:9 +msgid "Recommended skill level: low." +msgstr "" + +#: open_research/open_research.md:11 +# header +msgid "## Table of contents" +msgstr "" + +#: open_research/open_research.md:13 +# ordered list +msgid "1. [Summary](#summary)" +msgstr "" + +#: open_research/open_research.md:14 +# ordered list +msgid "2. [How this will help you/ why this is useful](#how-this-will-help-you--why-this-is-useful)" +msgstr "" + +#: open_research/open_research.md:15 +# ordered list +msgid "3. [Open data](/open_research/01/opendata#open-data)" +msgstr "" + +#: open_research/open_research.md:16 +msgid " 1. [Steps to make your data open](/open_research/01/opendata#steps-to-make-your-data-open)" +msgstr "" + +#: open_research/open_research.md:17 +msgid " 1. [Step 1: Make your data available](/open_research/01/opendata#step-1-make-your-data-available)" +msgstr "" + +#: open_research/open_research.md:18 +msgid " 2. [Step 2: Make your data easy to understand](/open_research/01/opendata#step-2-make-your-data-easy-to-understand)" +msgstr "" + +#: open_research/open_research.md:19 +msgid " 3. [Step 3: Make your data easy to use](/open_research/01/opendata#step-3-make-your-data-easy-to-use)" +msgstr "" + +#: open_research/open_research.md:20 +msgid " 4. [Step 4: Make your data citeable](/open_research/01/opendata#step-4-make-your-data-citeable)" +msgstr "" + +#: open_research/open_research.md:21 +msgid " 2. [Barriers to data sharing](/open_research/01/opendata#barriers-to-data-sharing)" +msgstr "" + +#: open_research/open_research.md:22 +msgid " 1. [Privacy](/open_research/01/opendata#privacy)" +msgstr "" + +#: open_research/open_research.md:23 +msgid " 2. [National and commercially sensitive data](/open_research/01/opendata#national-and-commercially-sensitive-data)" +msgstr "" + +#: open_research/open_research.md:24 +# ordered list +msgid "4. [Open source software](/open_research/02/opensourcesoftware#open-source-software)" +msgstr "" + +#: open_research/open_research.md:25 +msgid " 1. [What is open source software?](/open_research/02/opensourcesoftware.html#what-is-open-source-software)" +msgstr "" + +#: open_research/open_research.md:26 +msgid " 2. [How running and contributing to open source software projects benefits you](/open_research/02/opensourcesoftware.html#how-running-and-contributing-to-open-source-software-projects-benefits-you)" +msgstr "" + +#: open_research/open_research.md:27 +msgid " 1. [Making your own work open source](/open_research/02/opensourcesoftware.html#making-your-own-work-open-source)" +msgstr "" + +#: open_research/open_research.md:28 +msgid " 2. [Contributing to others' open source software projects](/open_research/02/opensourcesoftware.html#contributing-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:29 +msgid " 3. [How open source software benefits research](/open_research/02/opensourcesoftware.html#how-open-source-software-benefits-research)" +msgstr "" + +#: open_research/open_research.md:30 +msgid " 4. [How to run your own open source software project](/open_research/02/opensourcesoftware.html#how-to-run-your-own-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:31 +msgid " 1. [Welcome users by adding information to your README](/open_research/02/opensourcesoftware.html#welcome-users-by-adding-information-to-your-readme)" +msgstr "" + +#: open_research/open_research.md:32 +msgid " 2. [Contributing guidelines](/open_research/02/opensourcesoftware.html#contributing-guidelines)" +msgstr "" + +#: open_research/open_research.md:33 +msgid " 3. [Code of conduct](/open_research/02/opensourcesoftware.html#code-of-conduct)" +msgstr "" + +#: open_research/open_research.md:34 +msgid " 5. [How to contribute to other's open source software projects](/open_research/02/opensourcesoftware.html#how-to-contribute-to-others-open-source-software-projects)" +msgstr "" + +#: open_research/open_research.md:35 +msgid " 1. [Anatomy of an open source software project](/open_research/02/opensourcesoftware.html#anatomy-of-an-open-source-software-project)" +msgstr "" + +#: open_research/open_research.md:36 +msgid " 2. [Contribute your changes](/open_research/02/opensourcesoftware.html#contribute-your-changes)" +msgstr "" + +#: open_research/open_research.md:37 +msgid " 3. [Looking for projects to contribute to and how to contribute to them](/open_research/02/opensourcesoftware.html#looking-for-projects-to-contribute-to-and-how-to-contribute-to-them)" +msgstr "" + +#: open_research/open_research.md:38 +msgid " 6. [Closed software](/open_research/02/opensourcesoftware.html#closed-software)" +msgstr "" + +#: open_research/open_research.md:39 +# ordered list +msgid "5. [Open hardware](/open_research/03/openhardware#open-hardware)" +msgstr "" + +#: open_research/open_research.md:40 +msgid " 1. [Why open hardware?](/open_research/03/openhardware#why-open-hardware)" +msgstr "" + +#: open_research/open_research.md:41 +msgid " 2. [Elements of an open source hardware project](/open_research/03/openhardware#elements-of-an-open-source-hardware-project)" +msgstr "" + +#: open_research/open_research.md:42 +msgid " 3. [Open source hardware processes and practices](/open_research/03/openhardware#open-source-hardware-processes-and-practices)" +msgstr "" + +#: open_research/open_research.md:43 +msgid " 1. [Designing your hardware](/open_research/03/openhardware#designing-your-hardware)" +msgstr "" + +#: open_research/open_research.md:44 +msgid " 2. [Hosting your design file](/open_research/03/openhardware#hosting-your-design-files)" +msgstr "" + +#: open_research/open_research.md:45 +msgid " 3. [Distributing open source hardware](/open_research/03/openhardware#distributing-open-source-hardware)" +msgstr "" + +#: open_research/open_research.md:46 +# ordered list +msgid "6. [Open access](/open_research/04/openaccess#open-access)" +msgstr "" + +#: open_research/open_research.md:47 +msgid " 1. [What is open access?](/open_research/04/openaccess#what-is-open-access)" +msgstr "" + +#: open_research/open_research.md:48 +msgid " 1. [Repositories and self-archiving](/open_research/04/openaccess#repositories-and-self-archiving)" +msgstr "" + +#: open_research/open_research.md:49 +msgid " 2. [Open access publishing](/open_research/04/openaccess#open-access-publishing)" +msgstr "" + +#: open_research/open_research.md:50 +msgid " 2. [Why does open access matter?](/open_research/04/openaccess#why-does-open-access-matter)" +msgstr "" + +#: open_research/open_research.md:51 +msgid " 3. [Best practice for open access](/open_research/04/openaccess#best-practice-for-open-access)" +msgstr "" + +#: open_research/open_research.md:52 +msgid " 1. [Self-archiving](/open_research/04/openaccess#self-archiving)" +msgstr "" + +#: open_research/open_research.md:53 +msgid " 2. [Publication](/open_research/04/openaccess#publication)" +msgstr "" + +#: open_research/open_research.md:54 +# ordered list +msgid "7. [Open notebooks](/open_research/05/opennotebooks#open-notebooks)" +msgstr "" + +#: open_research/open_research.md:55 +# ordered list +msgid "8. [Open scholarship](/open_research/06/openscholarship#open-scholarship)" +msgstr "" + +#: open_research/open_research.md:56 +msgid " 1. [Open educational resources](/open_research/06/openscholarship#open-educational-resources)" +msgstr "" + +#: open_research/open_research.md:57 +msgid " 2. [Equity, Diversity, Inclusion](/open_research/06/openscholarship#equity-diversity-inclusion)" +msgstr "" + +#: open_research/open_research.md:58 +msgid " 3. [Citizen science](/open_research/06/openscholarship#citizen-science)" +msgstr "" + +#: open_research/open_research.md:59 +# ordered list +msgid "9. [Checklists](/open_research/07/resources#checklists)" +msgstr "" + +#: open_research/open_research.md:60 +# ordered list +msgid "10. [What to learn next](/open_research/07/resources#what-to-learn-next)" +msgstr "" + +#: open_research/open_research.md:61 +# ordered list +msgid "11. [Further reading](/open_research/07/resources#further-reading)" +msgstr "" + +#: open_research/open_research.md:62 +# ordered list +msgid "12. [Definitions/glossary](/open_research/07/resources#definitionsglossary)" +msgstr "" + +#: open_research/open_research.md:63 +# ordered list +msgid "13. [Bibliography](/open_research/07/resources#bibliography)" +msgstr "" + +#: open_research/open_research.md:65 +# header +msgid "## Summary" +msgstr "" + +#: open_research/open_research.md:67 +msgid "Open research aims to transform research by making it more reproducible, transparent, re-usable, collaborative, accountable, and accessible to society. It pushes for change in the way that research is carried out and disseminated by digital tools. One definition of open research, [as given by the Organisation for Economic Co-operation and Development (OECD)](https://www.fct.pt/dsi/docs/Making_Open_Science_a_Reality.pdf \"Making Open Science a Reality, OECD Science, Technology and Industry Policy Papers No. 25\"), is the practice of making \"the primary outputs of publicly funded research results – publications and the research data – publicly accessible in digital format with no or minimal restriction.\" In order to achieve this openness in research, each element of the research process should:" +msgstr "" + +#: open_research/open_research.md:69 +# unordered list +msgid "- Be publicly available: It is difficult to use and benefit from knowledge hidden behind barriers such as passwords and paywalls." +msgstr "" + +#: open_research/open_research.md:70 +# unordered list +msgid "- Be reusable: Research outputs need to be licensed appropriately so that prospective users clearly know any limitations on re-use." +msgstr "" + +#: open_research/open_research.md:71 +# unordered list +msgid "- Be transparent: With appropriate metadata to provide clear statements of how research output was produced and what it contains." +msgstr "" + +#: open_research/open_research.md:73 +msgid "The research process typically has the following form: data is collected and then analysed (usually using software). This process may involve the use of specialist hardware. The results of the research are then published. Throughout the process it is good practice for researchers to document their working in notebooks. Open research aims to make each of these elements open:" +msgstr "" + +#: open_research/open_research.md:75 +# unordered list +msgid "- Open data: Documenting and sharing research data openly for re-use." +msgstr "" + +#: open_research/open_research.md:76 +# unordered list +msgid "- Open source software: Documenting research code and routines, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:77 +# unordered list +msgid "- Open hardware: Documenting designs, materials, and other relevant information related to hardware, and making them freely accessible and available." +msgstr "" + +#: open_research/open_research.md:78 +# unordered list +msgid "- Open access: Making all published outputs freely accessible for maximum use and impact." +msgstr "" + +#: open_research/open_research.md:79 +# unordered list +msgid "- Open notebooks: An emerging practice, documenting and sharing the experimental process of trial and error." +msgstr "" + +#: open_research/open_research.md:81 +msgid "These elements are expanded upon in this chapter." +msgstr "" + +#: open_research/open_research.md:83 +msgid "Open scholarship is a concept that extends open research further. It relates to making other aspects of scientific research open to the public, for example:" +msgstr "" + +#: open_research/open_research.md:85 +# unordered list +msgid "- Open educational resources: Making educational resources publicly available to be re-used and modified." +msgstr "" + +#: open_research/open_research.md:86 +# unordered list +msgid "- Equity, diversity, inclusion: Ensuring scholarship is open to anyone without barriers based on factors such as race, background, gender, and sexual orientation." +msgstr "" + +#: open_research/open_research.md:87 +# unordered list +msgid "- Citizen science: The inclusion of members of the public in scientific research." +msgstr "" + +#: open_research/open_research.md:89 +msgid "These elements are also discussed in detail in this chapter." +msgstr "" + +#: open_research/open_research.md:91 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: open_research/open_research.md:93 +msgid "There are five main schools of thought motivating open practices to benefit research:" +msgstr "" + +#: open_research/open_research.md:95 +msgid "| School | Belief | Aim |" +msgstr "" + +#: open_research/open_research.md:96 +msgid "| -------------------------- | -------------------- | ------------------------------------------------- |" +msgstr "" + +#: open_research/open_research.md:97 +msgid "| Infrastructure | Efficient research depends on the available tools and applications. | Creating openly available platforms, tools, and services for researchers. |" +msgstr "" + +#: open_research/open_research.md:98 +msgid "| Pragmatic | Knowledge-creation could be more efficient if researchers worked together. | Opening up the process of knowledge creation. |" +msgstr "" + +#: open_research/open_research.md:99 +msgid "| Measurement | Academic contributions today need alternative impact measurements. | Developing an alternative metric system for research impact. |" +msgstr "" + +#: open_research/open_research.md:100 +msgid "| Democratic | The access to knowledge is unequally distributed. | Making knowledge freely available for everyone. |" +msgstr "" + +#: open_research/open_research.md:101 +msgid "| Public | Research needs to be made accessible to the public. | Making research accessible for citizens. |" +msgstr "" + +#: open_research/open_research.md:103 +msgid "Open practices also benefit the researchers that propagate them. For example there is evidence [(Mckiernan et al. 2016)](https://elifesciences.org/articles/16800) that open access articles are cited more often, as shown by the metastudy presented in the figure below." +msgstr "" + +#: open_research/open_research.md:105 +msgid "| ![open_access_citatations](../figures/open_access_citatations.jpg) |" +msgstr "" + +#: open_research/open_research.md:106 +msgid "| -----------------------------------------------------|" +msgstr "" + +#: open_research/open_research.md:107 +msgid "| The relative citation rate (OA: non-OA) in 19 fields of research. This rate is defined as the mean citation rate of OA articles divided by the mean citation rate of non-OA articles. Multiple points for the same discipline indicate different estimates from the same study, or estimates from several studies. (See footnote 1 for references.) |" +msgstr "" + +#: open_research/open_research.md:109 +msgid "Another benefit of openness is that while research collaborations are essential to advancing knowledge, identifying and connecting with appropriate collaborators is not trivial. Open practices can make it easier for researchers to connect with one another by increasing the discoverability and visibility of one’s work, facilitating rapid access to novel data and software resources, and creating new opportunities to interact with and contribute to ongoing communal projects." +msgstr "" + diff --git a/book/content/po/rdm.es.po b/book/content/po/rdm.es.po new file mode 100644 index 00000000000..05a18fee6d0 --- /dev/null +++ b/book/content/po/rdm.es.po @@ -0,0 +1,1754 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: rdm/rdm.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: rdm/rdm.md:51 +msgid "" +msgstr "" + +#: rdm/rdm.md:53 +# header +msgid "## Summary" +msgstr "" + +#: rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: rdm/rdm.md:62 +msgid "" +msgstr "" + +#: rdm/rdm.md:64 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: rdm/rdm.md:74 +msgid "" +msgstr "" + +#: rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: rdm/rdm.md:87 +msgid "" +msgstr "" + +#: rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: rdm/rdm.md:100 +msgid "" +msgstr "" + +#: rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: rdm/rdm.md:113 +msgid "" +msgstr "" + +#: rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: rdm/rdm.md:164 +msgid "" +msgstr "" + +#: rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: rdm/rdm.md:189 +msgid "" +msgstr "" + +#: rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: rdm/rdm.md:209 +msgid "" +msgstr "" + +#: rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: rdm/rdm.md:216 +msgid "" +msgstr "" + +#: rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: rdm/rdm.md:238 +msgid "" +msgstr "" + +#: rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: rdm/rdm.md:252 +msgid "" +msgstr "" + +#: rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: rdm/rdm.md:289 +msgid "" +msgstr "" + +#: rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: rdm/rdm.md:311 +msgid "" +msgstr "" + +#: rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: rdm/rdm.md:315 +msgid "" +msgstr "" + +#: rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: rdm/rdm.md:341 +msgid "" +msgstr "" + +#: rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: rdm/rdm.md:426 +msgid "" +msgstr "" + +#: rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: rdm/rdm.md:430 +msgid "" +msgstr "" + +#: rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: rdm/rdm.md:484 +msgid "" +msgstr "" + +#: rdm/rdm.md:486 +# header +msgid "## Checklist" +msgstr "" + +#: rdm/rdm.md:488 +msgid "" +msgstr "" + +#: rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: rdm/rdm.md:507 +# header +msgid "## What to learn next" +msgstr "" + +#: rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: rdm/rdm.md:512 +# header +msgid "## Further reading" +msgstr "" + +#: rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: rdm/rdm.md:517 +msgid "" +msgstr "" + +#: rdm/rdm.md:519 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: rdm/rdm.md:521 +msgid "" +msgstr "" + +#: rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: rdm/rdm.md:527 +msgid "" +msgstr "" + +#: rdm/rdm.md:529 +# header +msgid "## Bibliography" +msgstr "" + +#: rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + diff --git a/book/content/po/rdm.pot b/book/content/po/rdm.pot new file mode 100644 index 00000000000..4b280b2f9e0 --- /dev/null +++ b/book/content/po/rdm.pot @@ -0,0 +1,1754 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: rdm/rdm.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: rdm/rdm.md:51 +msgid "" +msgstr "" + +#: rdm/rdm.md:53 +# header +msgid "## Summary" +msgstr "" + +#: rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: rdm/rdm.md:62 +msgid "" +msgstr "" + +#: rdm/rdm.md:64 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: rdm/rdm.md:74 +msgid "" +msgstr "" + +#: rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: rdm/rdm.md:87 +msgid "" +msgstr "" + +#: rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: rdm/rdm.md:100 +msgid "" +msgstr "" + +#: rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: rdm/rdm.md:113 +msgid "" +msgstr "" + +#: rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: rdm/rdm.md:164 +msgid "" +msgstr "" + +#: rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: rdm/rdm.md:189 +msgid "" +msgstr "" + +#: rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: rdm/rdm.md:209 +msgid "" +msgstr "" + +#: rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: rdm/rdm.md:216 +msgid "" +msgstr "" + +#: rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: rdm/rdm.md:238 +msgid "" +msgstr "" + +#: rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: rdm/rdm.md:252 +msgid "" +msgstr "" + +#: rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: rdm/rdm.md:289 +msgid "" +msgstr "" + +#: rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: rdm/rdm.md:311 +msgid "" +msgstr "" + +#: rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: rdm/rdm.md:315 +msgid "" +msgstr "" + +#: rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: rdm/rdm.md:341 +msgid "" +msgstr "" + +#: rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: rdm/rdm.md:426 +msgid "" +msgstr "" + +#: rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: rdm/rdm.md:430 +msgid "" +msgstr "" + +#: rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: rdm/rdm.md:484 +msgid "" +msgstr "" + +#: rdm/rdm.md:486 +# header +msgid "## Checklist" +msgstr "" + +#: rdm/rdm.md:488 +msgid "" +msgstr "" + +#: rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: rdm/rdm.md:507 +# header +msgid "## What to learn next" +msgstr "" + +#: rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: rdm/rdm.md:512 +# header +msgid "## Further reading" +msgstr "" + +#: rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: rdm/rdm.md:517 +msgid "" +msgstr "" + +#: rdm/rdm.md:519 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: rdm/rdm.md:521 +msgid "" +msgstr "" + +#: rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: rdm/rdm.md:527 +msgid "" +msgstr "" + +#: rdm/rdm.md:529 +# header +msgid "## Bibliography" +msgstr "" + +#: rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + diff --git a/book/content/po/rdm.tr.po b/book/content/po/rdm.tr.po new file mode 100644 index 00000000000..4b280b2f9e0 --- /dev/null +++ b/book/content/po/rdm.tr.po @@ -0,0 +1,1754 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: rdm/rdm.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: rdm/rdm.md:51 +msgid "" +msgstr "" + +#: rdm/rdm.md:53 +# header +msgid "## Summary" +msgstr "" + +#: rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: rdm/rdm.md:62 +msgid "" +msgstr "" + +#: rdm/rdm.md:64 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: rdm/rdm.md:74 +msgid "" +msgstr "" + +#: rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: rdm/rdm.md:87 +msgid "" +msgstr "" + +#: rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: rdm/rdm.md:100 +msgid "" +msgstr "" + +#: rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: rdm/rdm.md:113 +msgid "" +msgstr "" + +#: rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: rdm/rdm.md:164 +msgid "" +msgstr "" + +#: rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: rdm/rdm.md:189 +msgid "" +msgstr "" + +#: rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: rdm/rdm.md:209 +msgid "" +msgstr "" + +#: rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: rdm/rdm.md:216 +msgid "" +msgstr "" + +#: rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: rdm/rdm.md:238 +msgid "" +msgstr "" + +#: rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: rdm/rdm.md:252 +msgid "" +msgstr "" + +#: rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: rdm/rdm.md:289 +msgid "" +msgstr "" + +#: rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: rdm/rdm.md:311 +msgid "" +msgstr "" + +#: rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: rdm/rdm.md:315 +msgid "" +msgstr "" + +#: rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: rdm/rdm.md:341 +msgid "" +msgstr "" + +#: rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: rdm/rdm.md:426 +msgid "" +msgstr "" + +#: rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: rdm/rdm.md:430 +msgid "" +msgstr "" + +#: rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: rdm/rdm.md:484 +msgid "" +msgstr "" + +#: rdm/rdm.md:486 +# header +msgid "## Checklist" +msgstr "" + +#: rdm/rdm.md:488 +msgid "" +msgstr "" + +#: rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: rdm/rdm.md:507 +# header +msgid "## What to learn next" +msgstr "" + +#: rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: rdm/rdm.md:512 +# header +msgid "## Further reading" +msgstr "" + +#: rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: rdm/rdm.md:517 +msgid "" +msgstr "" + +#: rdm/rdm.md:519 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: rdm/rdm.md:521 +msgid "" +msgstr "" + +#: rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: rdm/rdm.md:527 +msgid "" +msgstr "" + +#: rdm/rdm.md:529 +# header +msgid "## Bibliography" +msgstr "" + +#: rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + diff --git a/book/content/po/rdm.zh_CN.po b/book/content/po/rdm.zh_CN.po new file mode 100644 index 00000000000..dd23f99389e --- /dev/null +++ b/book/content/po/rdm.zh_CN.po @@ -0,0 +1,1755 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: rdm/rdm.md:1 +# header +msgid "# Research Data Management" +msgstr "" + +#: rdm/rdm.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: rdm/rdm.md:5 +msgid "The following sections in this handbook provide useful context and complementary information to this chapter:" +msgstr "" + +#: rdm/rdm.md:7 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: rdm/rdm.md:8 +msgid "| --------------------------------------------------- | ---------- |" +msgstr "" + +#: rdm/rdm.md:9 +msgid "| [Version Control](/version_control/version_control) | Helpful |" +msgstr "" + +#: rdm/rdm.md:10 +msgid "| [Open Research](/open_research/open_research) | Helpful |" +msgstr "" + +#: rdm/rdm.md:12 +# header +msgid "## Table of Contents" +msgstr "" + +#: rdm/rdm.md:14 +# unordered list +msgid "- [Research Data Management](#research-data-management)" +msgstr "" + +#: rdm/rdm.md:15 +# unordered list +msgid " - [Prerequisites / recommended skill level](#prerequisites--recommended-skill-level)" +msgstr "" + +#: rdm/rdm.md:16 +# unordered list +msgid " - [Table of Contents](#table-of-contents)" +msgstr "" + +#: rdm/rdm.md:17 +# unordered list +msgid " - [Summary](#summary)" +msgstr "" + +#: rdm/rdm.md:18 +# unordered list +msgid " - [How this will help you/ why this is useful](#how-this-will-help-you-why-this-is-useful)" +msgstr "" + +#: rdm/rdm.md:19 +# unordered list +msgid " - [Chapter content](#chapter-content)" +msgstr "" + +#: rdm/rdm.md:20 +# unordered list +msgid " - [What Is Data?](#what-is-data)" +msgstr "" + +#: rdm/rdm.md:21 +# unordered list +msgid " - [The Research Data Lifecycle - A Model for Data Management](#the-research-data-lifecycle---a-model-for-data-management)" +msgstr "" + +#: rdm/rdm.md:22 +# unordered list +msgid " - [The FAIR principles and practices](#the-fair-principles-and-practices)" +msgstr "" + +#: rdm/rdm.md:23 +# unordered list +msgid " - [Theory](#theory)" +msgstr "" + +#: rdm/rdm.md:24 +# unordered list +msgid " - [Tools and indicators](#tools-and-indicators)" +msgstr "" + +#: rdm/rdm.md:25 +# unordered list +msgid " - [Metadata and identifiers - community standards](#metadata-and-identifiers---community-standards)" +msgstr "" + +#: rdm/rdm.md:26 +# unordered list +msgid " - [Storage and backup](#storage-and-backup)" +msgstr "" + +#: rdm/rdm.md:27 +# unordered list +msgid " - [Where to store data](#where-to-store-data)" +msgstr "" + +#: rdm/rdm.md:28 +# unordered list +msgid " - [Backups](#backups)" +msgstr "" + +#: rdm/rdm.md:29 +# unordered list +msgid " - [Data organisation in spreadsheets](#data-organisation-in-spreadsheets)" +msgstr "" + +#: rdm/rdm.md:30 +# unordered list +msgid " - [Documentation and metadata](#documentation-and-metadata)" +msgstr "" + +#: rdm/rdm.md:31 +# unordered list +msgid " - [Sharing and archiving data](#sharing-and-archiving-data)" +msgstr "" + +#: rdm/rdm.md:32 +# unordered list +msgid " - [Motivations for sharing data](#motivations-for-sharing-data)" +msgstr "" + +#: rdm/rdm.md:33 +# unordered list +msgid " - [Steps to share your data](#steps-to-share-your-data)" +msgstr "" + +#: rdm/rdm.md:34 +# unordered list +msgid " - [Step 1: Select what data you want to share](#step-1-select-what-data-you-want-to-share)" +msgstr "" + +#: rdm/rdm.md:35 +# unordered list +msgid " - [Step 2: Choose a data repository or other sharing platform](#step-2-choose-a-data-repository-or-other-sharing-platform)" +msgstr "" + +#: rdm/rdm.md:36 +# unordered list +msgid " - [Step 3: Upload your data and documentation](#step-3-upload-your-data-and-documentation)" +msgstr "" + +#: rdm/rdm.md:37 +# unordered list +msgid " - [Step 4: Choose a licence and link to your paper and code](#step-4-choose-a-licence-and-link-to-your-paper-and-code)" +msgstr "" + +#: rdm/rdm.md:38 +# unordered list +msgid " - [Barriers to data sharing](#barriers-to-data-sharing)" +msgstr "" + +#: rdm/rdm.md:39 +# unordered list +msgid " - [Privacy and data protection](#privacy-and-data-protection)" +msgstr "" + +#: rdm/rdm.md:40 +# unordered list +msgid " - [Consent](#consent)" +msgstr "" + +#: rdm/rdm.md:41 +# unordered list +msgid " - [Anonymisation](#anonymisation)" +msgstr "" + +#: rdm/rdm.md:42 +# unordered list +msgid " - [National and commercially sensitive data](#national-and-commercially-sensitive-data)" +msgstr "" + +#: rdm/rdm.md:43 +# unordered list +msgid " - [Personal Stories](#personal-stories)" +msgstr "" + +#: rdm/rdm.md:44 +# unordered list +msgid " - [Susanna-Assunta Sansone: from FAIR co-author to FAIR doer](#susanna-assunta-sansone-from-fair-co-author-to-fair-doer)" +msgstr "" + +#: rdm/rdm.md:45 +# unordered list +msgid " - [Checklist](#checklist)" +msgstr "" + +#: rdm/rdm.md:46 +# unordered list +msgid " - [What to learn next](#what-to-learn-next)" +msgstr "" + +#: rdm/rdm.md:47 +# unordered list +msgid " - [Further reading](#further-reading)" +msgstr "" + +#: rdm/rdm.md:48 +# unordered list +msgid " - [Definitions/glossary](#definitionsglossary)" +msgstr "" + +#: rdm/rdm.md:49 +# unordered list +msgid " - [Bibliography](#bibliography)" +msgstr "" + +#: rdm/rdm.md:51 +msgid "" +msgstr "" + +#: rdm/rdm.md:53 +# header +msgid "## Summary" +msgstr "" + +#: rdm/rdm.md:55 +msgid "Research Data Management (RDM) covers how research data can be stored, described and reused. Data here is used as a" +msgstr "" + +#: rdm/rdm.md:56 +msgid "generic term to encompass all digital objects. RDM is a key part in enabling reproducible research. RDM ensures" +msgstr "" + +#: rdm/rdm.md:57 +msgid "efficiency in research workflows, and also greater reach and impact, as data become FAIR (Findable, Accessible," +msgstr "" + +#: rdm/rdm.md:58 +msgid "Interoperable and Reuseable). Data should be stored in multiple locations and backed-up regularly to prevent loss or" +msgstr "" + +#: rdm/rdm.md:59 +msgid "data corruption. Clearly describing data using documentation and metadata ensures that others know how to access, use" +msgstr "" + +#: rdm/rdm.md:60 +msgid "and re-use your data, and also enable conditions for sharing and publishing data to be outlined." +msgstr "" + +#: rdm/rdm.md:62 +msgid "" +msgstr "" + +#: rdm/rdm.md:64 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: rdm/rdm.md:66 +msgid "To be able to share data that is understandable and re-usable by third parties, research data needs to be managed" +msgstr "" + +#: rdm/rdm.md:67 +msgid "properly. The FAIR principles provide guidance on how to make data discoverable and reusable. FAIR data is a key" +msgstr "" + +#: rdm/rdm.md:68 +msgid "component of reproducing an analysis. However, FAIR data is not a synonym for open data or quality data. This chapter" +msgstr "" + +#: rdm/rdm.md:69 +msgid "lays out good data management practice to allow you to plan your data management activities at the start of your" +msgstr "" + +#: rdm/rdm.md:70 +msgid "reproducible research project." +msgstr "" + +#: rdm/rdm.md:72 +# header +msgid "## Chapter content" +msgstr "" + +#: rdm/rdm.md:74 +msgid "" +msgstr "" + +#: rdm/rdm.md:76 +# header +msgid "### What Is Data?" +msgstr "" + +#: rdm/rdm.md:78 +msgid "Data are all digital objects that you use and produce during your research life cycle, encompassing datasets, software," +msgstr "" + +#: rdm/rdm.md:79 +msgid "code, workflow, models, figures, tables, images, articles. Data are your research asset. In some fields it's obvious" +msgstr "" + +#: rdm/rdm.md:80 +msgid "what data means - you have observations or results of simulations. However, in other fields, particularly in Social" +msgstr "" + +#: rdm/rdm.md:81 +msgid "Sciences, Humanities or Arts, you may be thinking \"I don't think I have any data\". A good way of thinking about what" +msgstr "" + +#: rdm/rdm.md:82 +msgid "might be classed as data that needs to be managed is to ask yourself the questions \"What is the information that I need" +msgstr "" + +#: rdm/rdm.md:83 +msgid "to use and write about in my paper or book?\", \"What information would I need to back up my conclusions?\" and \"What" +msgstr "" + +#: rdm/rdm.md:84 +msgid "information is needed by a third party to understand and possibly replicate the research that I've done?\". This" +msgstr "" + +#: rdm/rdm.md:85 +msgid "information is your data." +msgstr "" + +#: rdm/rdm.md:87 +msgid "" +msgstr "" + +#: rdm/rdm.md:89 +# header +msgid "### The Research Data Lifecycle - A Model for Data Management" +msgstr "" + +#: rdm/rdm.md:91 +msgid "Research data often follows a 'lifecycle' which follows the research project as it evolves; here is a" +msgstr "" + +#: rdm/rdm.md:92 +msgid "[video](https://www.ukdataservice.ac.uk/manage-data/lifecycle.aspx) that describes it. This model provides a useful" +msgstr "" + +#: rdm/rdm.md:93 +msgid "basis on which to plan for research data management, from data creation at the start of a research project, through to" +msgstr "" + +#: rdm/rdm.md:94 +msgid "publishing and sharing research at the end of the project, and archiving any research data for the long-term and for" +msgstr "" + +#: rdm/rdm.md:95 +msgid "future re-use once the project has ended." +msgstr "" + +#: rdm/rdm.md:97 +msgid "The research data lifecycle involves data creation, data use, data publication and sharing, data archiving and data" +msgstr "" + +#: rdm/rdm.md:98 +msgid "re-use or destruction. However, data have a longer lifespan than the research project that creates them." +msgstr "" + +#: rdm/rdm.md:100 +msgid "" +msgstr "" + +#: rdm/rdm.md:102 +# header +msgid "### The FAIR principles and practices" +msgstr "" + +#: rdm/rdm.md:104 +msgid "The FAIR guiding principles for scientific data management and stewardship {% cite Wilkinson2016fair %} have been" +msgstr "" + +#: rdm/rdm.md:105 +msgid "developed as guidelines to improve the findability, accessibility, interoperability and re-usability of digital assets;" +msgstr "" + +#: rdm/rdm.md:106 +msgid "all of which will support research reproducibility. Defined and endorsed by a growing community, these principles put a" +msgstr "" + +#: rdm/rdm.md:107 +msgid "specific emphasis on enhancing the ability of machines to automatically find and use digital objects, in addition to" +msgstr "" + +#: rdm/rdm.md:108 +msgid "supporting its reuse by individuals throughout their life cycle. The capacity of computational systems to find, access," +msgstr "" + +#: rdm/rdm.md:109 +msgid "interoperate, and reuse data, with none or minimal human intervention, is essential in today's data-driven era, where" +msgstr "" + +#: rdm/rdm.md:110 +msgid "humans increasingly rely on computational support to deal with data as a result of the increase in volume, velocity and" +msgstr "" + +#: rdm/rdm.md:111 +msgid "variety and complexity." +msgstr "" + +#: rdm/rdm.md:113 +msgid "" +msgstr "" + +#: rdm/rdm.md:115 +# header +msgid "#### Theory" +msgstr "" + +#: rdm/rdm.md:117 +msgid "Here is a [simple overview](https://www.go-fair.org/fair-principles) of what the FAIR principles recommend. In breif," +msgstr "" + +#: rdm/rdm.md:118 +msgid "data should be:" +msgstr "" + +#: rdm/rdm.md:120 +msgid "**Findable:** the first step in (re)using data is to find them, and descriptive metadata is essential." +msgstr "" + +#: rdm/rdm.md:122 +# unordered list +msgid "- F1. (Meta)data are assigned a globally unique and persistent identifier" +msgstr "" + +#: rdm/rdm.md:123 +# unordered list +msgid "- F2. Data are described with rich metadata (defined by R1 below)" +msgstr "" + +#: rdm/rdm.md:124 +# unordered list +msgid "- F3. Metadata clearly and explicitly include the identifier of the data they describe" +msgstr "" + +#: rdm/rdm.md:125 +# unordered list +msgid "- F4. (Meta)data are registered or indexed in a searchable resource" +msgstr "" + +#: rdm/rdm.md:127 +msgid "**Accessible:** to get data one needs to know if authentication and authorisation is necessary, or if data is open with" +msgstr "" + +#: rdm/rdm.md:128 +msgid "no restrictions." +msgstr "" + +#: rdm/rdm.md:130 +# unordered list +msgid "- A1. (Meta)data are retrievable by their identifier using a standardised communications protocol" +msgstr "" + +#: rdm/rdm.md:131 +# unordered list +msgid "- A1.1 The protocol is open, free, and universally implementable" +msgstr "" + +#: rdm/rdm.md:132 +# unordered list +msgid "- A1.2 The protocol allows for an authentication and authorisation procedure, where necessary" +msgstr "" + +#: rdm/rdm.md:133 +# unordered list +msgid "- A2. Metadata are accessible, even when the data are no longer available" +msgstr "" + +#: rdm/rdm.md:135 +msgid "**Interoperable:** data need to be integrated with other data and/or interoperate with applications or workflows." +msgstr "" + +#: rdm/rdm.md:137 +# unordered list +msgid "- I1. (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation." +msgstr "" + +#: rdm/rdm.md:138 +# unordered list +msgid "- I2. (Meta)data use vocabularies that follow FAIR principles" +msgstr "" + +#: rdm/rdm.md:139 +# unordered list +msgid "- I3. (Meta)data include qualified references to other (meta)data" +msgstr "" + +#: rdm/rdm.md:141 +msgid "**Reusable:** data should be well-described so that they can be used or replicated in different settings." +msgstr "" + +#: rdm/rdm.md:143 +# unordered list +msgid "- R1. Meta(data) are richly described with a plurality of accurate and relevant attributes" +msgstr "" + +#: rdm/rdm.md:144 +# unordered list +msgid "- R1.1. (Meta)data are released with a clear and accessible data usage license" +msgstr "" + +#: rdm/rdm.md:145 +# unordered list +msgid "- R1.2. (Meta)data are associated with detailed provenance" +msgstr "" + +#: rdm/rdm.md:146 +# unordered list +msgid "- R1.3. (Meta)data meet domain-relevant community standards" +msgstr "" + +#: rdm/rdm.md:148 +msgid "It is important to stress that making data 'FAIR' is not the same as making it 'open' (as accessibility principle" +msgstr "" + +#: rdm/rdm.md:149 +msgid "clearly explains). Data should be as open as possible, as closed as necessary." +msgstr "" + +#: rdm/rdm.md:151 +msgid "The FAIR principles refer to three types of entities: data (as any digital object), metadata (information about that" +msgstr "" + +#: rdm/rdm.md:152 +msgid "digital object), and infrastructure (such as software and repositories). For instance, the findability principle F4 defines" +msgstr "" + +#: rdm/rdm.md:153 +msgid "that both metadata and data are registered or indexed in a searchable resource (such as a data repository). For example," +msgstr "" + +#: rdm/rdm.md:154 +msgid "the FAIR principles are also being applied to [software](https://doi.org/10.6084/m9.figshare.7449239.v2), and projects" +msgstr "" + +#: rdm/rdm.md:155 +msgid "where the data and software are both FAIR the research is more likely to be reproducible." +msgstr "" + +#: rdm/rdm.md:157 +msgid "It is much easier to make data FAIR if you plan to do this from the beginning of your research project. One way to do" +msgstr "" + +#: rdm/rdm.md:158 +msgid "this is to create a Data Management Plan (DMP), in [DMPonline](https://dmponline.dcc.ac.uk/) or just as a text file, to" +msgstr "" + +#: rdm/rdm.md:159 +msgid "help you think through how to manage your data. The DMP should include information on data creation (volume," +msgstr "" + +#: rdm/rdm.md:160 +msgid "formats/types and workflows), data use (where the raw or 'live' data is being stored), data publication and data" +msgstr "" + +#: rdm/rdm.md:161 +msgid "archiving at the end of the project (long-term data storage, or what data is 'kept' at the end of a project). DMPs" +msgstr "" + +#: rdm/rdm.md:162 +msgid "should also regularly be updated as the research project progresses or diverge from the initial design." +msgstr "" + +#: rdm/rdm.md:164 +msgid "" +msgstr "" + +#: rdm/rdm.md:166 +# header +msgid "#### Tools and indicators" +msgstr "" + +#: rdm/rdm.md:168 +msgid "Altought started by a community operating in the life science, the FAIR principles have rapidly been adopted by" +msgstr "" + +#: rdm/rdm.md:169 +msgid "publishers, funders, and pan-disciplinary infrastructure programmes and societies, in all disciplines. Many groups and" +msgstr "" + +#: rdm/rdm.md:170 +msgid "organization are working to define guidances and tools to help researchers, as well as other stakeholders (such as" +msgstr "" + +#: rdm/rdm.md:171 +msgid "librarians, funders, publishers, and trainers) to make data FAIR and assess its FAIRness level." +msgstr "" + +#: rdm/rdm.md:173 +msgid "This rapid uptake and community involvement, however, has also caused some confusion and ambiguity on what FAIRness is" +msgstr "" + +#: rdm/rdm.md:174 +msgid "and how we can measure it. It is important to say that the FAIR principles are aspirational, in that they do not" +msgstr "" + +#: rdm/rdm.md:175 +msgid "strictly define how to achieve a state of FAIRness, but rather describe a continuum of features, attributes, and" +msgstr "" + +#: rdm/rdm.md:176 +msgid "behaviors that will move a digital resource closer to that goal." +msgstr "" + +#: rdm/rdm.md:178 +msgid "Listing all efforts working in and around FAIRness is practically impossible, as this is a fast moving, disperse and" +msgstr "" + +#: rdm/rdm.md:179 +msgid "diverse field. Nevethless, if you are interested in following the discussion and/or participate in it, here are two" +msgstr "" + +#: rdm/rdm.md:180 +msgid "global and international initiatives that act as umbrella organizations and reference points for many discipline" +msgstr "" + +#: rdm/rdm.md:181 +msgid "specific efforts: [GOFAIR](https://www.go-fair.org) and the [Research Data Alliance (RDA)](https://www.rd-alliance.org)." +msgstr "" + +#: rdm/rdm.md:182 +msgid "Under GOFAIR there are many [Implementation Networks (INs)](https://www.go-fair.org/implementation-networks) committed" +msgstr "" + +#: rdm/rdm.md:183 +msgid "to implementing elements of the Internet of FAIR Data and Services within the three pillars: GO Build (Technology), GO" +msgstr "" + +#: rdm/rdm.md:184 +msgid "Change (Culture) and GO Train (Training). Under the RDA there are several groups tackling different aspects relevant to" +msgstr "" + +#: rdm/rdm.md:185 +msgid "the RDM life cycle, and among these one [group](https://www.rd-alliance.org/groups/fair-data-maturity-model-wg) is" +msgstr "" + +#: rdm/rdm.md:186 +msgid "reviewing existing efforts, building on them to define a common set of common assessment criteria for the evaluation of" +msgstr "" + +#: rdm/rdm.md:187 +msgid "FAIRness. Watch this space!" +msgstr "" + +#: rdm/rdm.md:189 +msgid "" +msgstr "" + +#: rdm/rdm.md:191 +# header +msgid "#### Metadata and identifiers - community standards" +msgstr "" + +#: rdm/rdm.md:193 +msgid "Metadata (to describe and report the data) and unique persistent identifiers (to cite and reference data) are the two" +msgstr "" + +#: rdm/rdm.md:194 +msgid "pillars of the FAIR principles. The use of community-defined standards for metadata and identified is vital for" +msgstr "" + +#: rdm/rdm.md:195 +msgid "high-quality, reproducible research and for the integrative analysis and comparison of heterogeneous data from multiple" +msgstr "" + +#: rdm/rdm.md:196 +msgid "sources, domains and disciplines. Although also in this areas there is a lot of work in progress, and expecially" +msgstr "" + +#: rdm/rdm.md:197 +msgid "metadata standards are disciplines specific, or specific to a given digital object, you need to know what these are and" +msgstr "" + +#: rdm/rdm.md:198 +msgid "which one are relevant to your data type in order to mention them in your DMP and use them." +msgstr "" + +#: rdm/rdm.md:200 +msgid "You can use [FAIRsharing](https://fairsharing.org) as a lookup resource to identify and cite the metadata and/or" +msgstr "" + +#: rdm/rdm.md:201 +msgid "identifier schemas, databases or repositories that exist for your data and discipline, for example, when creating a data" +msgstr "" + +#: rdm/rdm.md:202 +msgid "management plan for a grant proposal or funded project; or when submitting a manuscript to a journal, to identify the" +msgstr "" + +#: rdm/rdm.md:203 +msgid "recommended databases and repositories, as well as the standards they implement to ensure all relevant information about" +msgstr "" + +#: rdm/rdm.md:204 +msgid "the data is collected at the source. FAIRsharing also operates under GOFAIR and the RDA, and is" +msgstr "" + +#: rdm/rdm.md:205 +msgid "[widely adopted](https://fairsharing.org/communities) by publishers, funders, and other organizations; like any other" +msgstr "" + +#: rdm/rdm.md:206 +msgid "FAIR-enabling resources, it will continue to evolve, better linking to DMP and FAIRness assessment tools, to better help" +msgstr "" + +#: rdm/rdm.md:207 +msgid "you maing data FAIR a reality." +msgstr "" + +#: rdm/rdm.md:209 +msgid "" +msgstr "" + +#: rdm/rdm.md:211 +# header +msgid "### Storage and backup" +msgstr "" + +#: rdm/rdm.md:213 +msgid "Data loss can be catastrophic for your research project and can happen often. You can prevent data loss by picking" +msgstr "" + +#: rdm/rdm.md:214 +msgid "suitable storage solutions and backing your data up frequently." +msgstr "" + +#: rdm/rdm.md:216 +msgid "" +msgstr "" + +#: rdm/rdm.md:218 +# header +msgid "#### Where to store data" +msgstr "" + +#: rdm/rdm.md:220 +# unordered list +msgid "- Most institutions will provide a _network drive_ that you can use to store data." +msgstr "" + +#: rdm/rdm.md:221 +# unordered list +msgid "- _Portable storage media_ such as memory sticks (USB sticks) are more risky and vulnerable to loss and damage." +msgstr "" + +#: rdm/rdm.md:222 +# unordered list +msgid "- _Cloud storage_ provides a convenient way to store, back and up and retrieve data. You should check terms of use" +msgstr "" + +#: rdm/rdm.md:223 +msgid " before using them for your research data." +msgstr "" + +#: rdm/rdm.md:225 +msgid "Especially if you are handling personal or sensitive data, you need to ensure the cloud option is compliant with any" +msgstr "" + +#: rdm/rdm.md:226 +msgid "data protection rules the data is bound by. To add an additional layer of security, you should encrypt devices and/or" +msgstr "" + +#: rdm/rdm.md:227 +msgid "files where needed." +msgstr "" + +#: rdm/rdm.md:229 +msgid "Your institution might provide local storage solutions and policies or guidelines restricting what you can use. Thus, we" +msgstr "" + +#: rdm/rdm.md:230 +msgid "recommend you familiarise yourself with your local policies anc recommendations." +msgstr "" + +#: rdm/rdm.md:232 +msgid "When you are ready to release the data to the wider community, you can also search for the appropriate" +msgstr "" + +#: rdm/rdm.md:233 +msgid "[databases and repositories](https://fairsharing.org/databases) in FAIRsharing, according to your data type, and type of" +msgstr "" + +#: rdm/rdm.md:234 +msgid "access to the data. Major" +msgstr "" + +#: rdm/rdm.md:235 +msgid "[publishers are progressively defining clearer recommendations for data deposition and sharing](https://fairsharing.org/recommendations)," +msgstr "" + +#: rdm/rdm.md:236 +msgid "endorsing specific generics as well as domain-sepecific databases and repositories." +msgstr "" + +#: rdm/rdm.md:238 +msgid "" +msgstr "" + +#: rdm/rdm.md:240 +# header +msgid "#### Backups" +msgstr "" + +#: rdm/rdm.md:242 +msgid "To avoid loosing your data, you should follow good backup practices." +msgstr "" + +#: rdm/rdm.md:244 +# unordered list +msgid "- You should have 2 or 3 copies of your files, stored on" +msgstr "" + +#: rdm/rdm.md:245 +# unordered list +msgid "- at least 2 different storage media," +msgstr "" + +#: rdm/rdm.md:246 +# unordered list +msgid "- in different locations." +msgstr "" + +#: rdm/rdm.md:248 +msgid "The more important the data and the more often the datasets change, the more frequently you should back them up. If your" +msgstr "" + +#: rdm/rdm.md:249 +msgid "files take up a large amount of space and backing up all of them would be difficult or expensive, you may want to create" +msgstr "" + +#: rdm/rdm.md:250 +msgid "a set of criteria for when you back up the data. This can be part of your data management plan." +msgstr "" + +#: rdm/rdm.md:252 +msgid "" +msgstr "" + +#: rdm/rdm.md:254 +# header +msgid "### Data organisation in spreadsheets" +msgstr "" + +#: rdm/rdm.md:256 +msgid "Spreadsheets, such as Microsoft Excel files, are commonly used to collect, store, manipulate, analyse, and share" +msgstr "" + +#: rdm/rdm.md:257 +msgid "research data. Spreadsheets are convenient and easy-to-use tools for these tasks but are not amenable to reproducibility" +msgstr "" + +#: rdm/rdm.md:258 +msgid "if used as dynamic documents. There is a collection of [horror-stories](http://www.eusprig.org/horror-stories.htm) that" +msgstr "" + +#: rdm/rdm.md:259 +msgid "document the many ways that the use of spreadsheets have scuppered analyses due to unexpected behaviour or error-prone" +msgstr "" + +#: rdm/rdm.md:260 +msgid "editing processes. Some of these mishaps are not unique to spreadsheets, but" +msgstr "" + +#: rdm/rdm.md:261 +msgid "[many are](https://doi.org/10.1186/s13059-016-1044-7)." +msgstr "" + +#: rdm/rdm.md:263 +msgid "Data manipulation and analysis in spreadsheets in particular is best avoided as, without version control, it can lead to" +msgstr "" + +#: rdm/rdm.md:264 +msgid "non-reproducible workflows. By opening and editing raw data files directly by hand, for example to change values or" +msgstr "" + +#: rdm/rdm.md:265 +msgid "perform calculations, the process by which new values are obtained is not properly documented, and you may accidentally" +msgstr "" + +#: rdm/rdm.md:266 +msgid "over-write something or type in the wrong value only to notice after it's too late (or not at all)." +msgstr "" + +#: rdm/rdm.md:268 +msgid "Even if these errors are avoided, if the spreadsheet is poorly organised then it may be" +msgstr "" + +#: rdm/rdm.md:269 +msgid "[difficult for collaborators](https://luisdva.github.io/pls-don't-do-this/) to easily [read-in and re-use](#FAIR) your" +msgstr "" + +#: rdm/rdm.md:270 +msgid "data for further analysis." +msgstr "" + +#: rdm/rdm.md:272 +msgid "It's often not practical to avoid the use of spreadsheets altogether but there are some simple steps that can be taken" +msgstr "" + +#: rdm/rdm.md:273 +msgid "to mitigate their flaws. The following principles, taken from Broman et al. {% cite Broman2018data --suppress_author %}," +msgstr "" + +#: rdm/rdm.md:274 +msgid "provide some practical advice to ensure your data is clearly organised and human- and machine-readable:" +msgstr "" + +#: rdm/rdm.md:276 +# unordered list +msgid "- Be consistent" +msgstr "" + +#: rdm/rdm.md:277 +# unordered list +msgid "- Write dates as YYYY-MM-DD" +msgstr "" + +#: rdm/rdm.md:278 +# unordered list +msgid "- Don't leave any cells empty" +msgstr "" + +#: rdm/rdm.md:279 +# unordered list +msgid "- Put just one thing in a cell" +msgstr "" + +#: rdm/rdm.md:280 +# unordered list +msgid "- Organize the data as a single rectangle" +msgstr "" + +#: rdm/rdm.md:281 +# unordered list +msgid "- Create a data dictionary" +msgstr "" + +#: rdm/rdm.md:282 +# unordered list +msgid "- Don't include calculations in the raw data files" +msgstr "" + +#: rdm/rdm.md:283 +# unordered list +msgid "- Don’t use font color or highlighting as data" +msgstr "" + +#: rdm/rdm.md:284 +# unordered list +msgid "- Choose good names for things" +msgstr "" + +#: rdm/rdm.md:285 +# unordered list +msgid "- Make backups" +msgstr "" + +#: rdm/rdm.md:286 +# unordered list +msgid "- Use data validation to avoid data entry mistakes" +msgstr "" + +#: rdm/rdm.md:287 +# unordered list +msgid "- Save the data in plain text files" +msgstr "" + +#: rdm/rdm.md:289 +msgid "" +msgstr "" + +#: rdm/rdm.md:291 +# header +msgid "### Documentation and metadata" +msgstr "" + +#: rdm/rdm.md:293 +msgid "Having data available is of no use if it cannot be understood. For example a table of numbers is useless if there are no" +msgstr "" + +#: rdm/rdm.md:294 +msgid "headings which describe what the columns/rows contain. Therefore you should ensure that open datasets include consistent" +msgstr "" + +#: rdm/rdm.md:295 +msgid "core metadata, and that the data is fully described. This requires that all documentation accompanying data is written" +msgstr "" + +#: rdm/rdm.md:296 +msgid "in clear, plain language, and that data users have sufficient information to understand the source, strengths," +msgstr "" + +#: rdm/rdm.md:297 +msgid "weaknesses, and analytical limitations of the data so that they can make informed decisions when using it." +msgstr "" + +#: rdm/rdm.md:299 +# unordered list +msgid "- The level of documentation and metadata will vary according to the project and the range of people the data needs to" +msgstr "" + +#: rdm/rdm.md:300 +msgid " be understood by" +msgstr "" + +#: rdm/rdm.md:301 +# unordered list +msgid "- It is best practice to use recognised community metadata standards to make it easier for datasets to be combined. For" +msgstr "" + +#: rdm/rdm.md:302 +msgid " example, for brain data the [Brain Imaging Data Structure](https://doi.org/10.25504/FAIRsharing.rd1j6t) is the" +msgstr "" + +#: rdm/rdm.md:303 +msgid " strandards to use; other [metadata standards](https://fairsharing.org/standards)(reporting requirements," +msgstr "" + +#: rdm/rdm.md:304 +msgid " termonologies, and models/schemas) are searchable in FAIRsharing." +msgstr "" + +#: rdm/rdm.md:305 +# unordered list +msgid "- Variables should be defined and explained using" +msgstr "" + +#: rdm/rdm.md:306 +msgid " [data dictionaries](http://help.osf.io/m/bestpractices/l/618767-how-to-make-a-data-dictionary)" +msgstr "" + +#: rdm/rdm.md:307 +# unordered list +msgid "- Data should be stored in logical and heirarchical folder structures with a README file used to describe the structure." +msgstr "" + +#: rdm/rdm.md:308 +msgid " The README file is helpful for others and will also help you find your data in the future" +msgstr "" + +#: rdm/rdm.md:309 +msgid " {% cite Fuchs2018documentation %}." +msgstr "" + +#: rdm/rdm.md:311 +msgid "" +msgstr "" + +#: rdm/rdm.md:313 +# header +msgid "### Sharing and archiving data" +msgstr "" + +#: rdm/rdm.md:315 +msgid "" +msgstr "" + +#: rdm/rdm.md:317 +# header +msgid "#### Motivations for sharing data" +msgstr "" + +#: rdm/rdm.md:319 +msgid "The world is witnessing a significant global transformation, facilitated by technology and digital media, and fueled by" +msgstr "" + +#: rdm/rdm.md:320 +msgid "data and information. This transformation has enormous potential to foster more transparent, accountable, efficient," +msgstr "" + +#: rdm/rdm.md:321 +msgid "responsive, and effective research. Only a very small proportion of the original data is published in conventional" +msgstr "" + +#: rdm/rdm.md:322 +msgid "scientific journals. Existing policies on data archiving notwithstanding, in today’s practice data are primarily stored" +msgstr "" + +#: rdm/rdm.md:323 +msgid "in private files, not in secure institutional repositories, and effectively are lost to the public. This lack of access" +msgstr "" + +#: rdm/rdm.md:324 +msgid "to scientific data is an obstacle to international research for two main reasons:" +msgstr "" + +#: rdm/rdm.md:326 +# ordered list +msgid "1. It is generally difficult or impossible to fully reproduce a scientific study without the original data." +msgstr "" + +#: rdm/rdm.md:327 +# ordered list +msgid "2. It often causes unnecessary duplication of research efforts; large amounts of research funds are spent every year to" +msgstr "" + +#: rdm/rdm.md:328 +msgid " recreate already existing data. Furthermore, it inhibits joint research activities on various aspects of the same" +msgstr "" + +#: rdm/rdm.md:329 +msgid " problem." +msgstr "" + +#: rdm/rdm.md:331 +msgid "Accordingly, there is an ongoing global data revolution that seeks to advance collaboration and the creation and" +msgstr "" + +#: rdm/rdm.md:332 +msgid "expansion of effective, efficient research programs. Sharing data openly is crucial to meeting these objectives. Open" +msgstr "" + +#: rdm/rdm.md:333 +msgid "data means that the data is freely available on the internet permitting any user to download, copy, analyse, re-process," +msgstr "" + +#: rdm/rdm.md:334 +msgid "and re-use it for any other purpose without financial, legal, or technical barriers other than those inseparable from" +msgstr "" + +#: rdm/rdm.md:335 +msgid "gaining access to the internet itself. This represents a real shift in how research works. At the moment anyone who" +msgstr "" + +#: rdm/rdm.md:336 +msgid "wishes to use scientific data from a researcher often has to contact that researcher and make a request. Open by default" +msgstr "" + +#: rdm/rdm.md:337 +msgid "turns this on its head and says that there should be a presumption of publication for all. Researchers need to justify" +msgstr "" + +#: rdm/rdm.md:338 +msgid "data that’s kept closed, for example for security or data protection reasons. Free access to, and subsequent use of," +msgstr "" + +#: rdm/rdm.md:339 +msgid "data is of significant value to society and the economy, and that data should, therefore, be open by default. Research" +msgstr "" + +#: rdm/rdm.md:340 +msgid "is often publically-funded, so the results of this research should be openly available as a public good." +msgstr "" + +#: rdm/rdm.md:341 +msgid "" +msgstr "" + +#: rdm/rdm.md:343 +# header +msgid "### Steps to share your data" +msgstr "" + +#: rdm/rdm.md:345 +# header +msgid "#### Step 1: Select what data you want to share" +msgstr "" + +#: rdm/rdm.md:347 +msgid "Not all data can be made openly available, due to ethical and commercial concerns, and you may decide that some of your" +msgstr "" + +#: rdm/rdm.md:348 +msgid "intermediate data is too large to share. So you first need to decide which data you need to share for others to be able" +msgstr "" + +#: rdm/rdm.md:349 +msgid "to reproduce your research." +msgstr "" + +#: rdm/rdm.md:351 +# header +msgid "#### Step 2: Choose a data repository or other sharing platform" +msgstr "" + +#: rdm/rdm.md:353 +msgid "Data should be shared in a formal, open, and indexed data repository where possible so that it will be accessible in the" +msgstr "" + +#: rdm/rdm.md:354 +msgid "long-run. Suitable data repositories by subject, content type or location can be found at" +msgstr "" + +#: rdm/rdm.md:355 +msgid "[Re3data.org](https://www.re3data.org/) and in [FAIRsharing](https://fairsharing.org/databases) where you can also see" +msgstr "" + +#: rdm/rdm.md:356 +msgid "which standards (metadata and identifier) the repositories implement and which journal/publisher recommend them. If" +msgstr "" + +#: rdm/rdm.md:357 +msgid "possible use a repository which assigns a DOI, a digital object identifier, to make it easier for others to cite your" +msgstr "" + +#: rdm/rdm.md:358 +msgid "data." +msgstr "" + +#: rdm/rdm.md:360 +# header +msgid "#### Step 3: Upload your data and documentation" +msgstr "" + +#: rdm/rdm.md:362 +msgid "In line with the FAIR principles outlined above upload the data in open formats as much as possible and include" +msgstr "" + +#: rdm/rdm.md:363 +msgid "sufficient documentation and metadata that someone else can understand your data." +msgstr "" + +#: rdm/rdm.md:365 +# header +msgid "#### Step 4: Choose a licence and link to your paper and code" +msgstr "" + +#: rdm/rdm.md:367 +msgid "So that others know what they can do with your data you need to apply a licence to your data. The most commonly used" +msgstr "" + +#: rdm/rdm.md:368 +msgid "licences are [Creative Commons](https://creativecommons.org/choose/)," +msgstr "" + +#: rdm/rdm.md:369 +msgid "[Open Government Licence](http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/), or an" +msgstr "" + +#: rdm/rdm.md:370 +msgid "[Open Data Commons Attribution License](https://opendatacommons.org/licenses/by/index.html). To get maximum value from" +msgstr "" + +#: rdm/rdm.md:371 +msgid "data sharing make sure that your paper and code both link to your data, and vice versa, to allow others to best" +msgstr "" + +#: rdm/rdm.md:372 +msgid "understand your project. " +msgstr "" + +#: rdm/rdm.md:374 +# header +msgid "### Barriers to data sharing" +msgstr "" + +#: rdm/rdm.md:376 +msgid "Some academics still find sharing data difficult. Recent surveys {% cite Stuart2018sharing %} amongst researchers find" +msgstr "" + +#: rdm/rdm.md:377 +msgid "that sharing data is challenging for the following reasons:" +msgstr "" + +#: rdm/rdm.md:379 +# unordered list +msgid "- Organising data in a presentable and useful way (mentioned by 46%)," +msgstr "" + +#: rdm/rdm.md:380 +# unordered list +msgid "- Unsure about copyright and licensing as mentioned by 37%," +msgstr "" + +#: rdm/rdm.md:381 +# unordered list +msgid "- Not knowing which repository to use as raised by 33%." +msgstr "" + +#: rdm/rdm.md:383 +msgid "These are cultural challenges that might be addressed in changing practice going forward. However, there are also legal," +msgstr "" + +#: rdm/rdm.md:384 +msgid "ethical or contractual reasons that sometimes prevent making data publicly available in its entirety or even in parts." +msgstr "" + +#: rdm/rdm.md:385 +msgid "Those will be addressed in the following paragraphs." +msgstr "" + +#: rdm/rdm.md:387 +# header +msgid "#### Privacy and data protection" +msgstr "" + +#: rdm/rdm.md:389 +msgid "Many fields of scientific disciplines involve working with sensitive personal data. Their management is well regulated" +msgstr "" + +#: rdm/rdm.md:390 +msgid "in data protection legislation (in Europe through national implementations of the General Data Protection Regulation)" +msgstr "" + +#: rdm/rdm.md:391 +msgid "and ethics procedures as they are established in most research institutions {% cite EU2016protection %}." +msgstr "" + +#: rdm/rdm.md:393 +# header +msgid "##### Consent" +msgstr "" + +#: rdm/rdm.md:395 +msgid "In order to make sure that anonymised research data can be made available for future reuse, it is important that consent" +msgstr "" + +#: rdm/rdm.md:396 +msgid "forms cover sharing anonymised data with other researchers. Research so far suggests that study participants are usually" +msgstr "" + +#: rdm/rdm.md:397 +msgid "less concerned about the data being archived and shared than researchers think {% cite Kuula2010archiving %}." +msgstr "" + +#: rdm/rdm.md:398 +msgid "Participant information sheets and consent forms should include how research data will be stored, preserved and used in" +msgstr "" + +#: rdm/rdm.md:399 +msgid "the long-term, and how confidentiality will be protected when needed." +msgstr "" + +#: rdm/rdm.md:401 +# header +msgid "##### Anonymisation" +msgstr "" + +#: rdm/rdm.md:403 +msgid "Individuals must be protected from (re)identification via their personal data used for research. Anonymisation of the" +msgstr "" + +#: rdm/rdm.md:404 +msgid "data may be sufficient in some cases, but ensuring that reidentification is not possible is becoming increasingly" +msgstr "" + +#: rdm/rdm.md:405 +msgid "difficult and might be impossible due to technical progress, growing computational power and – ironically – more open" +msgstr "" + +#: rdm/rdm.md:406 +msgid "data. For example reidentification may be possible via data-mining of accessible data and so-called quasi-identifiers, a" +msgstr "" + +#: rdm/rdm.md:407 +msgid "set of (common) properties that are – in their combination – so specific that they can be used to identify. Preserving" +msgstr "" + +#: rdm/rdm.md:408 +msgid "privacy may still be possible if partial or generalised datasets are provided. For example, providing age bands instead" +msgstr "" + +#: rdm/rdm.md:409 +msgid "of birth date or only the first two digits of postal codes. It may also be possible to provide the data in such a format" +msgstr "" + +#: rdm/rdm.md:410 +msgid "that researchers can query it whist keeping the data itself closed. For example, a user may be able to send a query to" +msgstr "" + +#: rdm/rdm.md:411 +msgid "retrieve the mean of a dataset, but not be able to access any of the individual datapoints. Another way to provide" +msgstr "" + +#: rdm/rdm.md:412 +msgid "anonymized data is to provide [synthetic data](https://en.wikipedia.org/wiki/Synthetic_data), data generated to reflect" +msgstr "" + +#: rdm/rdm.md:413 +msgid "the conditions and properties of the raw data without including any of the personal information." +msgstr "" + +#: rdm/rdm.md:415 +# header +msgid "#### National and commercially sensitive data" +msgstr "" + +#: rdm/rdm.md:417 +msgid "In many cases companies are understandably unwilling to publish much of their data. The reasoning goes that if" +msgstr "" + +#: rdm/rdm.md:418 +msgid "commercially sensitive information of a company is disclosed, it will damage the company’s commercial interests and" +msgstr "" + +#: rdm/rdm.md:419 +msgid "undermine competitiveness. This is based on the thinking that in competitive markets, innovation will only occur with" +msgstr "" + +#: rdm/rdm.md:420 +msgid "some protection of information: if a company spends time and money developing something new, the details of which are" +msgstr "" + +#: rdm/rdm.md:421 +msgid "then made public, then its competitors can easily copy it without having to invest the same resources. The result is" +msgstr "" + +#: rdm/rdm.md:422 +msgid "that no-one would innovate in the first place. Similarly governments are often unwilling to publish data that relates to" +msgstr "" + +#: rdm/rdm.md:423 +msgid "issues such as national security due to public safety concerns. In such cases it may not be possible to make data open," +msgstr "" + +#: rdm/rdm.md:424 +msgid "or it may only be only possible to share partial/obscured datasets as outlined in the section above on privacy." +msgstr "" + +#: rdm/rdm.md:426 +msgid "" +msgstr "" + +#: rdm/rdm.md:428 +# header +msgid "## Personal Stories" +msgstr "" + +#: rdm/rdm.md:430 +msgid "" +msgstr "" + +#: rdm/rdm.md:432 +# header +msgid "### Susanna-Assunta Sansone: from FAIR co-author to FAIR doer" +msgstr "" + +#: rdm/rdm.md:434 +msgid "Let's start with my digital footprints so that you can discovery my activities:" +msgstr "" + +#: rdm/rdm.md:436 +# unordered list +msgid "- [Biography](https://www.eng.ox.ac.uk/people/susanna-assunta-sansone)" +msgstr "" + +#: rdm/rdm.md:437 +# unordered list +msgid "- [The Data Readiness group I run at Oxford University](https://sansonegroup.eng.ox.ac.uk)" +msgstr "" + +#: rdm/rdm.md:438 +# unordered list +msgid "- [ORCID: 0000-0001-5306-5690](https://orcid.org/0000-0001-5306-5690)" +msgstr "" + +#: rdm/rdm.md:439 +# unordered list +msgid "- [Profile on LinkedIn](https://uk.linkedin.com/in/sasansone)" +msgstr "" + +#: rdm/rdm.md:440 +# unordered list +msgid "- [Talks on SlideShare](https://www.slideshare.net/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:441 +# unordered list +msgid "- [Twitter; yes I am the FAIRlady](https://twitter.com/SusannaASansone)" +msgstr "" + +#: rdm/rdm.md:442 +# unordered list +msgid "- [Activities on GitHub; yeah, no code sorry](https://github.com/SusannaSansone)" +msgstr "" + +#: rdm/rdm.md:443 +# unordered list +msgid "- [Google Scholar](https://scholar.google.co.uk/citations?user=gfJ8wsIAAAAJ&hl=en)" +msgstr "" + +#: rdm/rdm.md:445 +msgid "I have worked on research data management since 2001, yes, way before this area was even considered a 'thing'. I was" +msgstr "" + +#: rdm/rdm.md:446 +msgid "also told that there is no career to make in research data management. Well, how wrong that comment was! Formely seen as" +msgstr "" + +#: rdm/rdm.md:447 +msgid "intersection between service provision and IT, data management has become a first class citizen, recognized as a" +msgstr "" + +#: rdm/rdm.md:448 +msgid "research and development subject, as it should be. A lot of the credit for this change goes to the FAIR principles. Love" +msgstr "" + +#: rdm/rdm.md:449 +msgid "it or hate it, FAIR is now an internationally-known lighthouse brand. Since we published the first article on the" +msgstr "" + +#: rdm/rdm.md:450 +msgid "[FAIR principles](https://doi.org/10.1038/sdata.2016.18), enabling FAIR has been my focus." +msgstr "" + +#: rdm/rdm.md:452 +msgid "The reuse of other people’s data is providing useful insights for new research questions and products, and driving new" +msgstr "" + +#: rdm/rdm.md:453 +msgid "scientific discoveries. To realize its potential, however, we need new mechanisms to manage the growing availability and" +msgstr "" + +#: rdm/rdm.md:454 +msgid "scale of scholarly digital products, such as datasets, software, algorithms, articles. FAIR has been specifically" +msgstr "" + +#: rdm/rdm.md:455 +msgid "designed to emphasise the machine-readablity of these digital objects." +msgstr "" + +#: rdm/rdm.md:457 +msgid "With my group of research software and knowledge engineerings we address the grand challenges related to information" +msgstr "" + +#: rdm/rdm.md:458 +msgid "science and scholarly communications, where data quality and readiness for (re)use is a prerequisite for success. I" +msgstr "" + +#: rdm/rdm.md:459 +msgid "believe that better data means better science, and this underpins reusable research, aids scholarly publishing, and" +msgstr "" + +#: rdm/rdm.md:460 +msgid "enables faster and reliable data-driven discoveries. As I say in my [one minute video](https://youtu.be/3VDw7XIulIk), my" +msgstr "" + +#: rdm/rdm.md:461 +msgid "vision is to transform the concept of data readiness into a powerful toolkit at the researchers’ fingertips, to realize" +msgstr "" + +#: rdm/rdm.md:462 +msgid "FAIR data by stealth." +msgstr "" + +#: rdm/rdm.md:464 +msgid "FAIR is not a magic wand. There is a lot to be done to enable and enact this transformation. We need all hands on deck!" +msgstr "" + +#: rdm/rdm.md:465 +msgid "Researchers, service providers, journal publishers, library science experts, funders and learned societies in the" +msgstr "" + +#: rdm/rdm.md:466 +msgid "academic as well as in the commercial and governmental setting all play a role: from providing use cases, to drive" +msgstr "" + +#: rdm/rdm.md:467 +msgid "policy and culture changes that motivates, rewards and credits researchers for disseminating and publishing" +msgstr "" + +#: rdm/rdm.md:468 +msgid "high-quality, machine-readable data; to building tools and services, to inform, training and educate." +msgstr "" + +#: rdm/rdm.md:470 +msgid "There are many community efforts around FAIR; keeping abreast with these is an activity in itself. I spend considerable" +msgstr "" + +#: rdm/rdm.md:471 +msgid "time to bring my group activities (such as [ISA](https://isa-tools.org) and [FAIRsharing](https://fairsharing.org)) in" +msgstr "" + +#: rdm/rdm.md:472 +msgid "and under larger international umbrella organizations like" +msgstr "" + +#: rdm/rdm.md:473 +msgid "[GOFAIR](https://www.go-fair.org/implementation-networks/overview/fair-strepo) and the" +msgstr "" + +#: rdm/rdm.md:474 +msgid "[RDA](http://dx.doi.org/10.15497/RDA00030) to interact with others, learn from them, compare and contrast efforts and" +msgstr "" + +#: rdm/rdm.md:475 +msgid "build new collaborations. I also play leading roles, seating on boards and chairing working groups with collagues," +msgstr "" + +#: rdm/rdm.md:476 +msgid "because you must get your hands dirty and lead by example." +msgstr "" + +#: rdm/rdm.md:478 +msgid "In research data management, the history is the future. The one I envision is a future where scientific evidences are" +msgstr "" + +#: rdm/rdm.md:479 +msgid "routinely available in a transparent, trustworthy and persistent manner to support peer-review and withstand" +msgstr "" + +#: rdm/rdm.md:480 +msgid "reproducibility, to underpin new results and discoveries, and effectively drive sciences forward." +msgstr "" + +#: rdm/rdm.md:482 +msgid "My advice: be aware, be FAIR!" +msgstr "" + +#: rdm/rdm.md:484 +msgid "" +msgstr "" + +#: rdm/rdm.md:486 +# header +msgid "## Checklist" +msgstr "" + +#: rdm/rdm.md:488 +msgid "" +msgstr "" + +#: rdm/rdm.md:490 +# unordered list +msgid "- [ ] Don't Touch the Raw Data - back it up somewhere reasonable and keep a read-only copy." +msgstr "" + +#: rdm/rdm.md:492 +# unordered list +msgid "- [ ] Have a plan! - Decide where your data is going to be stored, what its called, when/if it needs to be deleted" +msgstr "" + +#: rdm/rdm.md:493 +msgid " BEFORE you start collecting it and note it down in a data management plan. If you collect sensitive data, plan for" +msgstr "" + +#: rdm/rdm.md:494 +msgid " consent for sharing from the start!" +msgstr "" + +#: rdm/rdm.md:496 +# unordered list +msgid "- [ ] Document Everything - You know who the worst person at replying to emails is about what the sampling frequency of" +msgstr "" + +#: rdm/rdm.md:497 +msgid " channel X was. Nope not him, it's actually yourself from a year ago. Keep the documentation with the data!" +msgstr "" + +#: rdm/rdm.md:499 +# unordered list +msgid "- [ ] Create the data you want to see in the word - Imagine someone was about to give you a dataset that you needed to" +msgstr "" + +#: rdm/rdm.md:500 +msgid " analyse well in order to get that job you've been dreaming about. What would you want it to look like? That's how" +msgstr "" + +#: rdm/rdm.md:501 +msgid " yours should look." +msgstr "" + +#: rdm/rdm.md:503 +# unordered list +msgid "- [ ] Try not to re-invent the wheel. Before you start creating some crazy new schema, storage format or naming" +msgstr "" + +#: rdm/rdm.md:504 +msgid " protocol - have a quick google, ask your colleagues. Something that's already being used is likely going to be" +msgstr "" + +#: rdm/rdm.md:505 +msgid " better in the long run even if you think there's a better solution. " +msgstr "" + +#: rdm/rdm.md:507 +# header +msgid "## What to learn next" +msgstr "" + +#: rdm/rdm.md:509 +msgid "If you haven't read the chapter on Open Research yet, you might want to read it now for more context on how research" +msgstr "" + +#: rdm/rdm.md:510 +msgid "data management supports Open Research. " +msgstr "" + +#: rdm/rdm.md:512 +# header +msgid "## Further reading" +msgstr "" + +#: rdm/rdm.md:514 +# unordered list +msgid "- [Detailed guidance on sharng personal or sensitive data from the UK Data Service](https://www.ukdataservice.ac.uk/manage-data/legal-ethical/consent-data-sharing.aspx)" +msgstr "" + +#: rdm/rdm.md:515 +# unordered list +msgid "- [An overview of storage solutions and their advantages and disadvantages](https://datasupport.researchdata.nl/en/start-the-course/iii-the-research-phase/storing-data)" +msgstr "" + +#: rdm/rdm.md:517 +msgid "" +msgstr "" + +#: rdm/rdm.md:519 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: rdm/rdm.md:521 +msgid "" +msgstr "" + +#: rdm/rdm.md:523 +msgid "**RDM:** - Research Data Management " +msgstr "" + +#: rdm/rdm.md:524 +msgid "**DMP:** - Data Management Plan " +msgstr "" + +#: rdm/rdm.md:525 +msgid "**FAIR:** - Findable, Accessible, Interoperable and Reusable " +msgstr "" + +#: rdm/rdm.md:526 +msgid "**METADATA:** - Data that describes other data " +msgstr "" + +#: rdm/rdm.md:527 +msgid "" +msgstr "" + +#: rdm/rdm.md:529 +# header +msgid "## Bibliography" +msgstr "" + +#: rdm/rdm.md:531 +msgid "{% bibliography --cited %}" +msgstr "" + diff --git a/book/content/po/reproducibility.es.po b/book/content/po/reproducibility.es.po new file mode 100644 index 00000000000..8b6d07a2be9 --- /dev/null +++ b/book/content/po/reproducibility.es.po @@ -0,0 +1,444 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: reproducibility/04/resources.md:10 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: reproducibility/reproducibility.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: reproducibility/reproducibility.md:6 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: reproducibility/reproducibility.md:13 +# header +msgid "## Summary" +msgstr "" + +#: reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + diff --git a/book/content/po/reproducibility.pot b/book/content/po/reproducibility.pot new file mode 100644 index 00000000000..447df264991 --- /dev/null +++ b/book/content/po/reproducibility.pot @@ -0,0 +1,444 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: reproducibility/04/resources.md:10 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: reproducibility/reproducibility.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: reproducibility/reproducibility.md:6 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: reproducibility/reproducibility.md:13 +# header +msgid "## Summary" +msgstr "" + +#: reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + diff --git a/book/content/po/reproducibility.tr.po b/book/content/po/reproducibility.tr.po new file mode 100644 index 00000000000..447df264991 --- /dev/null +++ b/book/content/po/reproducibility.tr.po @@ -0,0 +1,444 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: reproducibility/04/resources.md:10 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: reproducibility/reproducibility.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: reproducibility/reproducibility.md:6 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: reproducibility/reproducibility.md:13 +# header +msgid "## Summary" +msgstr "" + +#: reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + diff --git a/book/content/po/reproducibility.zh_CN.po b/book/content/po/reproducibility.zh_CN.po new file mode 100644 index 00000000000..d62caf27c1e --- /dev/null +++ b/book/content/po/reproducibility.zh_CN.po @@ -0,0 +1,445 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducibility/01/importantforscience.md:1 +# header +msgid "# Why reproducibility is important for science" +msgstr "" + +#: reproducibility/01/importantforscience.md:3 +msgid "Major media outlets have [reported on](https://www.theguardian.com/science/2018/aug/27/attempt-to-replicate-major-social-scientific-findings-of-past-decade-fails) investigations showing that a significant percentage of scientific studies cannot be reproduced." +msgstr "" + +#: reproducibility/01/importantforscience.md:4 +msgid "This leads to other academics and society losing trust in scientific results (Baker, 2016)." +msgstr "" + +#: reproducibility/01/importantforscience.md:5 +msgid "Working reproducibly means others can check your results - even early on in the research process." +msgstr "" + +#: reproducibility/01/importantforscience.md:6 +msgid "Thus, the full analysis and methodology is transparent." +msgstr "" + +#: reproducibility/01/importantforscience.md:7 +msgid "Scientific results and evidence are strengthened if they are reproduced and confirmed by several independent researchers." +msgstr "" + +#: reproducibility/01/importantforscience.md:8 +msgid "With all parts used in an analysis being available and/or documented, valuable time is saved reproducing published results and other researchers can easily build on these resarch results and re-use data or code for their analyses." +msgstr "" + +#: reproducibility/01/importantforscience.md:9 +msgid "In addition, so called \"negative results\" can be published easily, helping avoid other researchers wasting time repeating analyses that will not return the expected results (Dirnagl & Lauritzen, 2010)." +msgstr "" + +#: reproducibility/02/whycare.md:1 +# header +msgid "# Why you should care about reproducibility" +msgstr "" + +#: reproducibility/02/whycare.md:3 +msgid "Markowetz highlights five reasons to work reproducibly (Markowetz, 2015):" +msgstr "" + +#: reproducibility/02/whycare.md:5 +# unordered list +msgid "- **Avoiding disaster**: By working reproducibly, you can trust your own research results and will not have to retract published results or keep publications back because you cannot reproduce your results." +msgstr "" + +#: reproducibility/02/whycare.md:6 +# unordered list +msgid "- **Writing papers easier**: Well documented analyses ensure that you have easy access to the latest results, your work can easily be written up, and collaborators can easily get on board as additional authors." +msgstr "" + +#: reproducibility/02/whycare.md:7 +msgid "Furthermore, you can be sure that you easily comply with the highest-level journal guidelines." +msgstr "" + +#: reproducibility/02/whycare.md:8 +# unordered list +msgid "- **Convincing reviewers**: Making code and data available to the reviewers means their review comments will be constructive as they are able to develop an in-depth understanding of your work and can even try changes to your analysis themselves and see the impact." +msgstr "" + +#: reproducibility/02/whycare.md:9 +# unordered list +msgid "- **Facilitating continuity of work**: Well documented work means your work can easily be picked up and continued - either by others in your laboratory, or yourself if you want to build on your own work after a longer period." +msgstr "" + +#: reproducibility/02/whycare.md:10 +# unordered list +msgid "- **Building your reputation**: Putting in effort to make your research reproducible shows that you are a careful researcher and makes your research results more robust." +msgstr "" + +#: reproducibility/02/whycare.md:12 +msgid "Papers whose underlying data is available get cited more often (Piwowar, Day & Fridsma, 2007; Piwowar & Vision, 2013)." +msgstr "" + +#: reproducibility/02/whycare.md:13 +msgid "All research outputs that are shared can be built upon more easily by others and in some cases, others following up on your work might lead to new collaborations." +msgstr "" + +#: reproducibility/02/whycare.md:14 +msgid "Other benefits of working openly are covered in our [Open Research](../open_research/open_research) chapter." +msgstr "" + +#: reproducibility/03/definitions.md:1 +# header +msgid "# Definitions of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:3 +msgid "The most common definition of reproducibility (and replication) was first noted by Claerbout and Karrenbach in 1992 and has been used in computational science literature since then." +msgstr "" + +#: reproducibility/03/definitions.md:4 +msgid "Another popular definition has been introduced in 2013 by the Association for Computing Machinery (ACM), which swapped the meaning of the terms 'reproducible' and 'replicable' compared to Claerbout and Karrenbach." +msgstr "" + +#: reproducibility/03/definitions.md:5 +msgid "The following table contrasts both definitions following Heroux et al. (2018)." +msgstr "" + +#: reproducibility/03/definitions.md:7 +msgid "| Term | Claerbout & Karrenbach | ACM |" +msgstr "" + +#: reproducibility/03/definitions.md:8 +msgid "| -----|------------------------|-----|" +msgstr "" + +#: reproducibility/03/definitions.md:9 +msgid "| Reproducible | Authors provide all the necessary data and the computer codes to run the analysis again, re-creating the results.| (Different team, different experimental setup.) The measurement can be obtained with stated precision by a different team, a different measuring system, in a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using artifacts which they develop completely independently. |" +msgstr "" + +#: reproducibility/03/definitions.md:10 +msgid "| Replicable | A study that arrives at the same scientific findings as another study, collecting new data (possibly with different methods) and completing new analyses. | (Different team, same experimental setup.) The measurement can be obtained with stated precision by a different team using the same measurement procedure, the same measuring system, under the same operating conditions, in the same or a different location on multiple trials. For computational experiments, this means that an independent group can obtain the same result using the author's own artifacts. |" +msgstr "" + +#: reproducibility/03/definitions.md:12 +msgid "Barba (2018) conducted a detailed literature review on the usage of reproducible/replicable covering several disciplines." +msgstr "" + +#: reproducibility/03/definitions.md:13 +msgid "Most papers and disciplines use the terminology as defined by Claerbout and Karrenbach, whereas mircobiology, immunology and computer science tend to follow the ACM use of reproducibility and replication." +msgstr "" + +#: reproducibility/03/definitions.md:14 +msgid "In political science and economics literature, both terms are used interchangeably." +msgstr "" + +#: reproducibility/03/definitions.md:16 +msgid "In addition to these high level definitions of reporducibility, some authors provide more detailed disctinctions." +msgstr "" + +#: reproducibility/03/definitions.md:17 +msgid "Victoria Stodden [(2014)](http://edge.org/response-detail/25340), a prominent scholar on this topic, has for example identified the following further distinctions:" +msgstr "" + +#: reproducibility/03/definitions.md:19 +# unordered list +msgid "- _Computational reproducibility_: When detailed information is provided about code, software, hardware and implementation details." +msgstr "" + +#: reproducibility/03/definitions.md:21 +# unordered list +msgid "- _Empirical reproducibility_: When detailed information is provided about non-computational empirical scientific experiments and observations. In practice this is enabled by making data freely available, as well as details of how the data was collected." +msgstr "" + +#: reproducibility/03/definitions.md:23 +# unordered list +msgid "- _Statistical reproducibility_: When detailed information is provided, for example, about the choice of statistical tests, model parameters, and threshold values. This mostly relates to pre-registration of study design to prevent p-value hacking and other manipulations." +msgstr "" + +#: reproducibility/03/definitions.md:25 +# header +msgid "## The Turing Way definition of reproducibility" +msgstr "" + +#: reproducibility/03/definitions.md:27 +msgid "The Turing Way project will define reproducible research as both data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/03/definitions.md:29 +msgid "| ![Kirstie's definition of reproducible research](../../figures/reproducibility/ReproducibleMatrix.jpg) |" +msgstr "" + +#: reproducibility/03/definitions.md:30 +msgid "| -------------------------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducibility/03/definitions.md:31 +msgid "| How the Turing Way defines reproducible research |" +msgstr "" + +#: reproducibility/03/definitions.md:33 +msgid "However, we recognize that some research will use sensitive data that cannot be shared and this handbook will provide guides on how your research can be reproducible without all parts necessarily being open." +msgstr "" + +#: reproducibility/03/definitions.md:35 +msgid "The handbook will cover:" +msgstr "" + +#: reproducibility/03/definitions.md:36 +# unordered list +msgid "* Open research" +msgstr "" + +#: reproducibility/03/definitions.md:37 +# unordered list +msgid "* Version control (using git)" +msgstr "" + +#: reproducibility/03/definitions.md:38 +# unordered list +msgid "* Collaborating on GitHub/GitLab" +msgstr "" + +#: reproducibility/03/definitions.md:39 +# unordered list +msgid "* Credit for reproducible research" +msgstr "" + +#: reproducibility/03/definitions.md:40 +# unordered list +msgid "* Research data management" +msgstr "" + +#: reproducibility/03/definitions.md:41 +# unordered list +msgid "* Reproducible environments" +msgstr "" + +#: reproducibility/03/definitions.md:42 +# unordered list +msgid "* Testing" +msgstr "" + +#: reproducibility/03/definitions.md:43 +# unordered list +msgid "* Reviewing" +msgstr "" + +#: reproducibility/03/definitions.md:44 +# unordered list +msgid "* Continuous integration" +msgstr "" + +#: reproducibility/03/definitions.md:45 +# unordered list +msgid "* Reproducible research with make" +msgstr "" + +#: reproducibility/03/definitions.md:46 +# unordered list +msgid "* Risk assessments" +msgstr "" + +#: reproducibility/03/definitions.md:47 +# unordered list +msgid "* Various case studies" +msgstr "" + +#: reproducibility/03/definitions.md:48 +# unordered list +msgid "* Checklists to get you started on reproducible practices" +msgstr "" + +#: reproducibility/04/resources.md:1 +# header +msgid "# Resources for reproducibility chapter" +msgstr "" + +#: reproducibility/04/resources.md:3 +# header +msgid "## Checklist / Exercise" +msgstr "" + +#: reproducibility/04/resources.md:4 +# unordered list +msgid "- [ ] Define reproducibility for yourself." +msgstr "" + +#: reproducibility/04/resources.md:6 +# header +msgid "## What to learn next?" +msgstr "" + +#: reproducibility/04/resources.md:7 +msgid "Open Research would be a good chapter to read next." +msgstr "" + +#: reproducibility/04/resources.md:8 +msgid "If you want to start learning hands-on practices, we recommend reading the Version Control chapter next." +msgstr "" + +#: reproducibility/04/resources.md:10 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducibility/04/resources.md:12 +# unordered list +msgid "* Baker, M. (2016). 1,500 scientists lift the lid on reproducibility. Nature, 533(7604), 452–454. https://doi.org/10.1038/533452a" +msgstr "" + +#: reproducibility/04/resources.md:14 +# unordered list +msgid "* Barba, L. (2018). Terminologies for Reproducible Research, arXiv preprint: https://arxiv.org/abs/1802.03311" +msgstr "" + +#: reproducibility/04/resources.md:16 +# unordered list +msgid "* Claerbout, J. F., & Karrenbach, M. (1992). Electronic documents give reproducible research a new meaning. In SEG Technical Program Expanded Abstracts 1992. Society of Exploration Geophysicists. https://doi.org/10.1190/1.1822162" +msgstr "" + +#: reproducibility/04/resources.md:18 +# unordered list +msgid "* Dirnagl, U., & Lauritzen, M. (2010). Fighting Publication Bias: Introducing the Negative Results Section. Journal of Cerebral Blood Flow & Metabolism, 30(7), 1263–1264. https://doi.org/10.1038/jcbfm.2010.51" +msgstr "" + +#: reproducibility/04/resources.md:20 +# unordered list +msgid "* Heroux, M. A., Barba, L., Parashar, M., Stodden, V., & Taufer, M. (2018). Toward a Compatible Reproducibility Taxonomy for Computational and Computing Sciences. Office of Scientific and Technical Information (OSTI). https://doi.org/10.2172/1481626" +msgstr "" + +#: reproducibility/04/resources.md:22 +# unordered list +msgid "* Markowetz, F. (2015). Five selfish reasons to work reproducibly. Genome Biology, 16(1). https://doi.org/10.1186/s13059-015-0850-7" +msgstr "" + +#: reproducibility/04/resources.md:24 +# unordered list +msgid "* Piwowar, H. A., Day, R. S., & Fridsma, D. B. (2007). Sharing Detailed Research Data Is Associated with Increased Citation Rate. PLoS ONE, 2(3), e308. https://doi.org/10.1371/journal.pone.0000308" +msgstr "" + +#: reproducibility/04/resources.md:26 +# unordered list +msgid "* Piwowar, H. A., & Vision, T. J. (2013). Data reuse and the open data citation advantage. PeerJ, 1, e175. https://doi.org/10.7717/peerj.175" +msgstr "" + +#: reproducibility/04/resources.md:28 +# unordered list +msgid "* Whitaker, Kirstie (2018): Barriers to reproducible research (and how to overcome them). figshare. Paper. https://doi.org/10.6084/m9.figshare.7140050.v2" +msgstr "" + +#: reproducibility/04/resources.md:30 +# header +msgid "## Additional material" +msgstr "" + +#: reproducibility/04/resources.md:31 +# header +msgid "### Videos" +msgstr "" + +#: reproducibility/04/resources.md:33 +# unordered list +msgid "* Markowetz, F. (2016). 5 selfish reasons to work reproducibly. Talk at scidata 2016. https://www.youtube.com/watch?v=Is15CMVPHas&feature=youtu.be" +msgstr "" + +#: reproducibility/04/resources.md:35 +# header +msgid "### Recommended reading" +msgstr "" + +#: reproducibility/04/resources.md:36 +# unordered list +msgid "* Barba, L. (2017): Barba-group Reproducibility Syllabus. figshare. Paper. https://doi.org/10.6084/m9.figshare.4879928.v1" +msgstr "" + +#: reproducibility/04/resources.md:38 +# header +msgid "### Other useful links" +msgstr "" + +#: reproducibility/04/resources.md:39 +# unordered list +msgid "* Markowetz, F. (2018). 5 selfish reasons to work reproducibly. Slides available at https://osf.io/a8wq4/" +msgstr "" + +#: reproducibility/reproducibility.md:1 +# header +msgid "# What is reproducible science?" +msgstr "" + +#: reproducibility/reproducibility.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducibility/reproducibility.md:4 +msgid "No previous knowledge needed." +msgstr "" + +#: reproducibility/reproducibility.md:6 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducibility/reproducibility.md:8 +# ordered list +msgid "1. [Why reproducibility is important for science](01/importantforscience)" +msgstr "" + +#: reproducibility/reproducibility.md:9 +# ordered list +msgid "2. [Why you should care about reproducibility](02/whycare)" +msgstr "" + +#: reproducibility/reproducibility.md:10 +# ordered list +msgid "3. [Definitions of reproducibility](03/definitions)" +msgstr "" + +#: reproducibility/reproducibility.md:11 +# ordered list +msgid "4. [Resources for reproducibility chapter](04/resources)" +msgstr "" + +#: reproducibility/reproducibility.md:13 +# header +msgid "## Summary" +msgstr "" + +#: reproducibility/reproducibility.md:14 +msgid "There are several definitions of reproducibility in use, and we discuss these in more detail in the [definitions](03/definitions) section of this chapter." +msgstr "" + +#: reproducibility/reproducibility.md:15 +msgid "The Turing Way defines reproducibility as data and code being available to fully rerun the analysis." +msgstr "" + +#: reproducibility/reproducibility.md:16 +msgid "This chapter will lay out why reproducibility is important for science and scientists, provide an overview of the most common definitions, and define reproducibility in the context of this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:18 +# header +msgid "## How this will help you / why this is useful" +msgstr "" + +#: reproducibility/reproducibility.md:19 +msgid "This chapter sets out the definition of reproducibility that the Turing Way project team used when writing this handbook." +msgstr "" + +#: reproducibility/reproducibility.md:20 +msgid "It will be useful to avoid misunderstandings when reading the rest of the handbook." +msgstr "" + diff --git a/book/content/po/reproducible_environments.es.po b/book/content/po/reproducible_environments.es.po new file mode 100644 index 00000000000..6b0d76a0309 --- /dev/null +++ b/book/content/po/reproducible_environments.es.po @@ -0,0 +1,3533 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: reproducible_environments/02/package-management.md:14 +#: reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: reproducible_environments/02/package-management.md:15 +#: reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:17 +#: reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: reproducible_environments/07/checklist.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/07/checklist.md:3 +# header +msgid "## Checklist" +msgstr "" + +#: reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: reproducible_environments/08/resources.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:3 +# header +msgid "## What to learn next" +msgstr "" + +#: reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: reproducible_environments/08/resources.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:9 +# header +msgid "## Further reading" +msgstr "" + +#: reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: reproducible_environments/08/resources.md:13 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:15 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: reproducible_environments/08/resources.md:35 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:37 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:46 +#: reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:15 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:75 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:77 +# header +msgid "## Summary" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:105 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:107 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + diff --git a/book/content/po/reproducible_environments.pot b/book/content/po/reproducible_environments.pot new file mode 100644 index 00000000000..a64a12f18b2 --- /dev/null +++ b/book/content/po/reproducible_environments.pot @@ -0,0 +1,3533 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: reproducible_environments/02/package-management.md:14 +#: reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: reproducible_environments/02/package-management.md:15 +#: reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:17 +#: reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: reproducible_environments/07/checklist.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/07/checklist.md:3 +# header +msgid "## Checklist" +msgstr "" + +#: reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: reproducible_environments/08/resources.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:3 +# header +msgid "## What to learn next" +msgstr "" + +#: reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: reproducible_environments/08/resources.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:9 +# header +msgid "## Further reading" +msgstr "" + +#: reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: reproducible_environments/08/resources.md:13 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:15 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: reproducible_environments/08/resources.md:35 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:37 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:46 +#: reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:15 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:75 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:77 +# header +msgid "## Summary" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:105 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:107 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + diff --git a/book/content/po/reproducible_environments.tr.po b/book/content/po/reproducible_environments.tr.po new file mode 100644 index 00000000000..a64a12f18b2 --- /dev/null +++ b/book/content/po/reproducible_environments.tr.po @@ -0,0 +1,3533 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: reproducible_environments/02/package-management.md:14 +#: reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: reproducible_environments/02/package-management.md:15 +#: reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:17 +#: reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: reproducible_environments/07/checklist.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/07/checklist.md:3 +# header +msgid "## Checklist" +msgstr "" + +#: reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: reproducible_environments/08/resources.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:3 +# header +msgid "## What to learn next" +msgstr "" + +#: reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: reproducible_environments/08/resources.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:9 +# header +msgid "## Further reading" +msgstr "" + +#: reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: reproducible_environments/08/resources.md:13 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:15 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: reproducible_environments/08/resources.md:35 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:37 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:46 +#: reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:15 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:75 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:77 +# header +msgid "## Summary" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:105 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:107 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + diff --git a/book/content/po/reproducible_environments.zh_CN.po b/book/content/po/reproducible_environments.zh_CN.po new file mode 100644 index 00000000000..d89e5336c3e --- /dev/null +++ b/book/content/po/reproducible_environments.zh_CN.po @@ -0,0 +1,3534 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reproducible_environments/01/options.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:3 +# header +msgid "## Summary of ways to capture computational environments" +msgstr "" + +#: reproducible_environments/01/options.md:5 +msgid "There are a number of ways of capturing computational environments. The major ones covered in this chapter will be package management systems, Binder, virtual machines, and containers. Each have their own pros and cons, and which is the most appropriate for you will depend on the nature of your project." +msgstr "" + +#: reproducible_environments/01/options.md:7 +msgid "These can be broadly split into two categories: those that capture only the software and its versions used in an environment (package management systems), and those that replicate an entire computational environment including the operating system and customised settings (virtual machines and containers)." +msgstr "" + +#: reproducible_environments/01/options.md:9 +msgid "Another way these can be split is by how the reproduced research is presented to the reproducer. Using Binder or a virtual machine creates a much more graphical, GUI-type result, whereas the outputs of containers and package management systems are more easily interacted with via the command line." +msgstr "" + +#: reproducible_environments/01/options.md:11 +# inline html +msgid "\n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +" \n" +"
Interaction style
GraphicalCommand line
What is reproduced?Software and versionsBinderConda
Entire systemVirtual MachinesContainers
" +msgstr "" + +#: reproducible_environments/01/options.md:36 +msgid "Here we give a brief description of each of these tools:" +msgstr "" + +#: reproducible_environments/01/options.md:38 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:40 +# header +msgid "### Package management systems" +msgstr "" + +#: reproducible_environments/01/options.md:42 +msgid "Package management systems are tools used to install and keep track of the software (and critically versions of software) used on a system, and can export files specifying these required software packages/versions. The files can be shared with others who can use them to replicate the environment, either manually or via their own package management systems." +msgstr "" + +#: reproducible_environments/01/options.md:44 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:46 +# header +msgid "### Binder" +msgstr "" + +#: reproducible_environments/01/options.md:48 +msgid "Binder is a service which generates fully-functioning versions of projects from a git repository and serves them on the cloud. These \"binderized\" projects can be accessed and interacted with by others via a web browser. In order to do this Binder requires that the software (and optionally versions) required to run the project are specified. Users can make use of package management systems or Dockerfiles (discussed in the [Containers section](#Containers_section)) to do this if they so desire." +msgstr "" + +#: reproducible_environments/01/options.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:52 +# header +msgid "### Virtual machines" +msgstr "" + +#: reproducible_environments/01/options.md:54 +msgid "Virtual machines are simulated computers. A user can make a \"virtual\" computer very easily, specifying the operating system they want it to have among other features, and run it like any other app. Within the app will be the desktop, file system, default software libraries and other features of the specified machine, which can be interacted with as if it was a real computer. Virtual machines can be easily replicated and shared. This allows researchers to create virtual machines, perform their research on them, and then save their state along with their files, settings and outputs, which they can then distribute as a fully-functioning project." +msgstr "" + +#: reproducible_environments/01/options.md:56 +msgid "" +msgstr "" + +#: reproducible_environments/01/options.md:58 +# header +msgid "### Containers" +msgstr "" + +#: reproducible_environments/01/options.md:60 +msgid "Containers offer many of the same benefits as virtual machines. They essentially act as entirely separate machines which can contain their own files, software and settings." +msgstr "" + +#: reproducible_environments/01/options.md:62 +msgid "The difference is that virtual machines include an entire operating system along with all the associated software. that is typically packaged with it- regardless of whether the project actually makes use of that associated software. Containers only contain the software and files explicitly defined within them in order to run the project they contain. This makes them far more lightweight than virtual machines." +msgstr "" + +#: reproducible_environments/01/options.md:64 +msgid "Containers are particularly useful if projects need to be able to run on high performance computing environments as, since they already _contain_ all the necessary software, they save having to install anything on an unfamiliar system where the researcher may not have the required permissions to do so." +msgstr "" + +#: reproducible_environments/02/package-management.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:3 +# header +msgid "## Package management systems" +msgstr "" + +#: reproducible_environments/02/package-management.md:5 +msgid "Package managers install and keep track of the different software packages (and their versions) that you use within an environment. There are quite a few to choose from, for example Yum, Zypper, dpkg, and Nix (which will be mentioned briefly later in the [Binder](#Binder_section) section). We're going to focus on [Conda](https://conda.io/en/latest/), which has a number of useful functionalities." +msgstr "" + +#: reproducible_environments/02/package-management.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:9 +# header +msgid "### What does Conda do?" +msgstr "" + +#: reproducible_environments/02/package-management.md:11 +msgid "Conda allows users to create any number of environments which are entirely separate, and to quickly and easily change between them." +msgstr "" + +#: reproducible_environments/02/package-management.md:12 +msgid "For example, say a researcher has a project: Project One, which has its own environment defined by Conda which is made up of a set of packages and versions of those packages:" +msgstr "" + +#: reproducible_environments/02/package-management.md:14 +#: reproducible_environments/02/package-management.md:22 +msgid "| Package name | Version |" +msgstr "" + +#: reproducible_environments/02/package-management.md:15 +#: reproducible_environments/02/package-management.md:23 +msgid "| ------------ | ------- |" +msgstr "" + +#: reproducible_environments/02/package-management.md:16 +msgid "| Package A | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:17 +#: reproducible_environments/02/package-management.md:24 +msgid "| Package B | 2.1.10 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:18 +msgid "| Package C | 0.7.9 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:20 +msgid "Later the researcher starts Project Two in its own environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:25 +msgid "| Package C | 1.2.4 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:26 +msgid "| Package D | 1.5.2 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:27 +msgid "| Package E | 3.7.1 |" +msgstr "" + +#: reproducible_environments/02/package-management.md:29 +msgid "Note here that the version of package C used in Project Two has been updated from the version used in Project One. If these project environments were not separate then the researcher would have the choice of:" +msgstr "" + +#: reproducible_environments/02/package-management.md:31 +# unordered list +msgid "- A) Using the older version of package C forever and not benefiting from updates and bugfixes in later versions." +msgstr "" + +#: reproducible_environments/02/package-management.md:32 +# unordered list +msgid "- B) Installing the updated version of the package and hoping that it doesn't impact Project One." +msgstr "" + +#: reproducible_environments/02/package-management.md:33 +# unordered list +msgid "- C) Installing the updated version of the package for use in Project Two then uninstalling it and reinstalling the old one whenever they need to do work on Project One. This would be extremely annoying, and is a step that risks being forgotten." +msgstr "" + +#: reproducible_environments/02/package-management.md:35 +msgid "All of these options are extremely poor, hence the utility of Conda for creating distinct environments which are easily interchangable." +msgstr "" + +#: reproducible_environments/02/package-management.md:37 +msgid "Conda can also be used to easily capture and export computational environments. It can go in the other direction too; it can generate computational environments from configuration files which can be used to recreate someone else's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:39 +msgid "Another benefit of Conda is that it offers much greater flexibility to users who do not have admin privileges on the machines they are working on (as is very common when working with high performance computing facilities). Without Conda it is typically very difficult to install required software onto such machines. However, because Conda creates and changes _new_ environments rather than making changes to a machine's overall system environment, admin privileges are not required." +msgstr "" + +#: reproducible_environments/02/package-management.md:41 +msgid "Finally, while Conda is Python-centric to a degree, it is also well integrated for use with other languages, for example the base version of Conda includes the C++ standard library." +msgstr "" + +#: reproducible_environments/02/package-management.md:43 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:45 +# header +msgid "### Installing Conda" +msgstr "" + +#: reproducible_environments/02/package-management.md:47 +msgid "Note that these installation instructions are directed towards Linux systems. Instructions for installing Conda on Windows or Mac systems can be found [here](https://docs.conda.io/projects/conda/en/latest/user-guide/install/)." +msgstr "" + +#: reproducible_environments/02/package-management.md:49 +msgid "Go to [https://repo.continuum.io/miniconda/](https://repo.continuum.io/miniconda/) and download the latest Miniconda 3 installer for your system (32 bit or 64 bit), which will have a name like Miniconda_version_number.sh. Run the installer using" +msgstr "" + +#: reproducible_environments/02/package-management.md:51 +# code block +msgid "```\n" +"bash Miniconda_version_number.sh\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:55 +msgid "You can check that Conda has installed successfully by typing" +msgstr "" + +#: reproducible_environments/02/package-management.md:57 +# code block +msgid "```\n" +"conda --version\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:61 +msgid "which should output a version number." +msgstr "" + +#: reproducible_environments/02/package-management.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:65 +# header +msgid "### Making and using environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:67 +msgid "Conda automatically installs a base environment with some commonly used software packages. It is possible to just work in this base environment, however it is good practise to create a new environment for each project you start." +msgstr "" + +#: reproducible_environments/02/package-management.md:69 +msgid "To create an environment use `conda create --name your_project_env_name` followed by a list of packages to include. To include the packages scipy and matplotlib, add them to the end of the command:" +msgstr "" + +#: reproducible_environments/02/package-management.md:71 +# code block +msgid "```\n" +"conda create --name Project_One scipy matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:75 +msgid "You can specify the versions of certain (or all) packages by using `=package_number` after the name. For example, to specify scipy 1.2.1 in the above environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:77 +# code block +msgid "```\n" +"conda create --name Project_One scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:81 +msgid "When creating environments you can also specify versions of languages to install, for example to use Python 3.7.1 in the Project_One environment:" +msgstr "" + +#: reproducible_environments/02/package-management.md:83 +# code block +msgid "```\n" +"conda create --name Project_One python=3.7.1 scipy=1.2.1 matplotlib\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:87 +msgid "Now that an environment has been created it's time to activate (start using) it via `conda activate environment_name`, so in this example:" +msgstr "" + +#: reproducible_environments/02/package-management.md:89 +# code block +msgid "```\n" +"conda activate Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:93 +msgid "Note that you may need to use `source` instead of `conda` if you're using an old version of conda." +msgstr "" + +#: reproducible_environments/02/package-management.md:95 +msgid "Once an environment is activated you should see the environment name before each prompt in your terminal:" +msgstr "" + +#: reproducible_environments/02/package-management.md:97 +# code block +msgid "```\n" +"(Project_One) $ python --version\n" +"Python 3.7.1\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:102 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:104 +# header +msgid "### Deactivating and deleting environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:106 +msgid "You can deactivate (get out of) an environment using" +msgstr "" + +#: reproducible_environments/02/package-management.md:108 +# code block +msgid "```\n" +"conda deactivate\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:112 +msgid "and remove (delete) an environment as shown here for removing the Project_One environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:114 +# code block +msgid "```\n" +"conda env remove --name Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:118 +msgid "To check if an environment has been successfully removed you can look at a list of all the Conda environments on the system using" +msgstr "" + +#: reproducible_environments/02/package-management.md:120 +# code block +msgid "```\n" +"conda env list\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:124 +msgid "However deleting an environment may not delete package files that were associated with it. This can lead to a lot of memory being wasted on packages that are no longer required. Packages that are no longer referenced by any environments can be deleted using" +msgstr "" + +#: reproducible_environments/02/package-management.md:126 +# code block +msgid "```\n" +"conda clean -pts\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:130 +msgid "Alternatively you can delete an environment (such as Project_One) along with its associated packages via:" +msgstr "" + +#: reproducible_environments/02/package-management.md:132 +# code block +msgid "```\n" +"conda remove --name Project_One --all\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:136 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:138 +# header +msgid "### Installing and removing packages within an environment" +msgstr "" + +#: reproducible_environments/02/package-management.md:140 +msgid "Within an environment you can install more packages using" +msgstr "" + +#: reproducible_environments/02/package-management.md:142 +# code block +msgid "```\n" +"conda install package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:146 +msgid "and similarly you can remove them via" +msgstr "" + +#: reproducible_environments/02/package-management.md:148 +# code block +msgid "```\n" +"conda remove package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:152 +msgid "This is the best way to install packages from within Conda as it will also install a Conda-tailored version of the package. However it is possible to use other methods if a Conda-specific version of a package is not available. For example `pip` is commonly used to install Python packages, so a command like" +msgstr "" + +#: reproducible_environments/02/package-management.md:154 +# code block +msgid "```\n" +"pip install scipy\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:158 +msgid "still works." +msgstr "" + +#: reproducible_environments/02/package-management.md:160 +msgid "Although Python packages have been used in many of the examples given here Conda packages do not have to be Python packages, for example here the R base language is installed along with the R package r-yaml" +msgstr "" + +#: reproducible_environments/02/package-management.md:162 +# code block +msgid "```\n" +"conda create --name Project_One r-base r-yaml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:166 +msgid "A Conda channel is where it downloaded a package from. Common channels include Anaconda (a company which provides the `defaults` conda package channel), and conda-forge (a community-driven packaging endeavour). You can explicitly install a package from a certain channel by specifying it like:" +msgstr "" + +#: reproducible_environments/02/package-management.md:168 +# code block +msgid "```\n" +"conda install -c channel_name package_name\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:172 +msgid "" +msgstr "" + +#: reproducible_environments/02/package-management.md:174 +# header +msgid "### Exporting and reproducing computational environments" +msgstr "" + +#: reproducible_environments/02/package-management.md:176 +msgid "Conda environments can be exported easily to human-readable files in the YAML format. YAML files are discussed in more detail [later](#YAML_files) in this chapter." +msgstr "" + +#: reproducible_environments/02/package-management.md:178 +msgid "To export a conda environment to a file called `environment.yml` activate the environment and then run" +msgstr "" + +#: reproducible_environments/02/package-management.md:180 +# code block +msgid "```\n" +"conda env export > environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:184 +msgid "Similarly Conda environments can be created from YAML files via" +msgstr "" + +#: reproducible_environments/02/package-management.md:186 +# code block +msgid "```\n" +"conda env create -f environment.yml\n" +"```" +msgstr "" + +#: reproducible_environments/02/package-management.md:190 +msgid "This allows researchers to easily reproduce one another's computational environments. Note that the list of packages is not just those explicitly installed. It can include OS-specific dependency packages so environment files may require some editing to be portable to different operating systems." +msgstr "" + +#: reproducible_environments/02/package-management.md:192 +msgid "Environments can also be cloned. This may be desirable, for example, if a researcher begins a new project and wants to make a new environment to work on it in, but the new project's environment (at least initially) requires the same packages as a previous project's environment." +msgstr "" + +#: reproducible_environments/02/package-management.md:194 +msgid "For example to clone the Project_One environment, and give this new environment the name Project_Two:" +msgstr "" + +#: reproducible_environments/02/package-management.md:196 +# code block +msgid "```\n" +"conda create --name Project_Two --clone Project_One\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:3 +# header +msgid "## YAML files" +msgstr "" + +#: reproducible_environments/03/yaml.md:5 +msgid "YAML is an indentation-based markup language which aims to be both easy to read and easy to write. Many projects use it for configuration files because of its readability, simplicity and good support for many programming languages. It can be used for a great many things including defining computational environments, and is well integrated with [Travis](https://travis-ci.org/) which is discussed in the chapter on continuous integration." +msgstr "" + +#: reproducible_environments/03/yaml.md:7 +msgid "An a YAML file defining a computational environment might look something like this:" +msgstr "" + +#: reproducible_environments/03/yaml.md:9 +# code block +msgid "```\n" +"# Define the operating system as Linux\n" +"os: linux\n" +"\n" +"# Use the xenial distribution of Linux\n" +"dist: xenial\n" +"\n" +"# Use the programming language Python\n" +"language: python\n" +"\n" +"# Use version of Python 3.2\n" +"python: 3.2\n" +"\n" +"# Use the Python package numpy and use version 1.16.1\n" +"packages:\n" +" numpy:\n" +" version: 1.16.1\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:28 +msgid "Note that as you can see here that comments can be added by preceding them with a `#`." +msgstr "" + +#: reproducible_environments/03/yaml.md:30 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:32 +# header +msgid "### YAML syntax" +msgstr "" + +#: reproducible_environments/03/yaml.md:34 +msgid "A YAML document can consist of the following elements." +msgstr "" + +#: reproducible_environments/03/yaml.md:36 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:38 +# header +msgid "#### Scalars" +msgstr "" + +#: reproducible_environments/03/yaml.md:40 +msgid "Scalars are ordinary values: numbers, strings, booleans." +msgstr "" + +#: reproducible_environments/03/yaml.md:42 +# code block +msgid "```\n" +"number-value: 42\n" +"floating-point-value: 3.141592\n" +"boolean-value: true\n" +"\n" +"# strings can be both 'single-quoted` and \"double-quoted\"\n" +"string-value: 'Bonjour'\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:51 +msgid "YAML syntax also allows unquoted string values for convenience reasons:" +msgstr "" + +#: reproducible_environments/03/yaml.md:53 +# code block +msgid "```\n" +"unquoted-string: Hello World\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:57 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:59 +# header +msgid "#### Lists and Dictionaries" +msgstr "" + +#: reproducible_environments/03/yaml.md:61 +msgid "Lists are collections of elements:" +msgstr "" + +#: reproducible_environments/03/yaml.md:63 +# code block +msgid "```\n" +"jedis:\n" +" - Yoda\n" +" - Qui-Gon Jinn\n" +" - Obi-Wan Kenobi\n" +" - Luke Skywalker\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:71 +msgid "Every element of the list is indented and starts with a dash and a space." +msgstr "" + +#: reproducible_environments/03/yaml.md:73 +msgid "Dictionaries are collections of `key: value` mappings. All keys are case-sensitive." +msgstr "" + +#: reproducible_environments/03/yaml.md:75 +# code block +msgid "```\n" +"jedi:\n" +" name: Obi-Wan Kenobi\n" +" home-planet: Stewjon\n" +" species: human\n" +" master: Qui-Gon Jinn\n" +" height: 1.82m\n" +"```" +msgstr "" + +#: reproducible_environments/03/yaml.md:84 +msgid "Note that a space after the colon is mandatory." +msgstr "" + +#: reproducible_environments/03/yaml.md:86 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:88 +# header +msgid "#### YAML gotchas" +msgstr "" + +#: reproducible_environments/03/yaml.md:90 +msgid "Due to the format aiming to be easy to write and read, there're some ambiguities in YAML." +msgstr "" + +#: reproducible_environments/03/yaml.md:92 +# unordered list +msgid "- **Special characters in unquoted strings:** YAML has a number of special characters you cannot use in unquoted strings. For example, parsing the following sample will fail:" +msgstr "" + +#: reproducible_environments/03/yaml.md:93 +# code block +msgid " ```\n" +" unquoted-string: let me put a colon here: oops\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:96 +msgid " Quote the string value makes this value unambiguous:" +msgstr "" + +#: reproducible_environments/03/yaml.md:97 +# code block +msgid " ```\n" +" unquoted-string: \"let me put a colon here: oops\"\n" +" ```" +msgstr "" + +#: reproducible_environments/03/yaml.md:100 +msgid " Generally, you should quote all strings that contain any of the following characters: `[] {} : > |`." +msgstr "" + +#: reproducible_environments/03/yaml.md:101 +# unordered list +msgid "- **Tabs versus spaces for indentation:** do _not_ use tabs for indentation. While resulting YAML can still be valid, this can be a source of many subtle" +msgstr "" + +#: reproducible_environments/03/yaml.md:102 +msgid " parsing errors. Just use spaces." +msgstr "" + +#: reproducible_environments/03/yaml.md:104 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:106 +# header +msgid "### How to use YAML to define computational environments" +msgstr "" + +#: reproducible_environments/03/yaml.md:108 +msgid "Because of their simplicity YAML files can be hand written. Alternatively they can be automatically generated as discussed [above](#Package_management_systems). From a YAML file a computational environment can be replicated in a few ways." +msgstr "" + +#: reproducible_environments/03/yaml.md:110 +# unordered list +msgid "- **Manually.** It can be done manually by carefully installing the specified packages. Because YAML files can also specify operating systems and versions that may or may not match that of the person trying to replicate the environment this may require the use of a [virtual machine](#Virtual_machines)." +msgstr "" + +#: reproducible_environments/03/yaml.md:111 +# unordered list +msgid "- **Via package management systems such as Conda.** As [discussed](#Package_management_systems) as well as being able to generate YAML files from computational environments Conda can also generate computational environments from YAML files." +msgstr "" + +#: reproducible_environments/03/yaml.md:113 +msgid "" +msgstr "" + +#: reproducible_environments/03/yaml.md:115 +# header +msgid "### Security issues" +msgstr "" + +#: reproducible_environments/03/yaml.md:117 +msgid "There is an inherent risk in downloading/using files you have not written to your computer, and it is possible to include malicious code in YAML files. Do not load YAML files or generate computational environments from them unless you trust their source." +msgstr "" + +#: reproducible_environments/04/binder.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:3 +# header +msgid "## Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:5 +msgid "Now that we've seen how to use and capture the computational environment used in a Python project, it's time to think about how to share that environment." +msgstr "" + +#: reproducible_environments/04/binder.md:7 +msgid "With an `environment.yml` file (or similar from alternative package management systems), it is possible for others to recreate the environment specified by that file. However, this relies on the new user having the same package management system set up, and knowing how to use it. It would be far easier if there was an automated solution to recreate the computational environment - and this is where Binder comes in." +msgstr "" + +#: reproducible_environments/04/binder.md:9 +msgid "Binder uses a tool called repo2docker to create a Docker image of a project based on the configuration files that are included. The resulting image contains the project and the computational environment specified by the original user. Other users can access the image via a cloud-based BinderHub, which allows them to view, edit and run the code from their web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:11 +msgid "Juliette Taka's excellent cartoon below illustrates the steps in creating and sharing a \"binderized\" project." +msgstr "" + +#: reproducible_environments/04/binder.md:13 +msgid "**Step 1:** We start with a researcher who has completed a project and wants to share her work with anyone, regardless of their computational environment. Note that Binder does not only have to be applied to finished projects; it can be used in exactly the same way to share projects that are in progress." +msgstr "" + +#: reproducible_environments/04/binder.md:15 +msgid "**Step 2:** The researcher's project contains many files of different types. In this case the researcher has been working in Jupyter notebooks, but Binder can be used just as effectively with many other file formats and languages which we'll cover in more detail shortly." +msgstr "" + +#: reproducible_environments/04/binder.md:17 +msgid "**Step 3:** The researcher uploads her code to a publicly available repository hosting service, such as GitHub, where it can be accessed by others. She includes a file describing the computational environment required to run the project." +msgstr "" + +#: reproducible_environments/04/binder.md:19 +msgid "**Step 4:** She generates a link at the [mybinder.org](https://mybinder.org) BinderHub. By clicking on this link anyone can access a \"Binderized\" version of her project. The click triggers repo2docker to build an Docker image based on the contents of the repository and its configuration files. This image is then hosted on the cloud. The person who clicked the link will be taken to a copy of her project in their web browser that they can interact with. This copy of the project they interact with is hosted in the environment the researcher specified in step 3, regardless of the computational environment of the person is accessing it from." +msgstr "" + +#: reproducible_environments/04/binder.md:21 +msgid "![binder_comic](../../figures/binder_comic.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:23 +msgid "Figure credit: [Juliette Taka, Logilab and the OpenDreamKit project](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/)" +msgstr "" + +#: reproducible_environments/04/binder.md:25 +msgid "To get an idea of what this looks like here's what a binder of a simple example project looks like. Files are listed and can be clicked on and modified by the person accessing the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:27 +msgid "![binder_home](../../figures/binder_home.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:29 +msgid "Users can also open terminals to run or otherwise interact with the files by clicking on \"New\" and then \"Terminal\" in the top right of the home binder screen shown above. Here this is used to run the analysis script in the example binder which performs a linear regression on some data:" +msgstr "" + +#: reproducible_environments/04/binder.md:31 +msgid "![binder_terminal](../../figures/binder_terminal.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:33 +msgid "As mentioned Binder is well integrated with Jupyter notebooks which can be opened by clicking on \"New\" and then under \"Notebook\" in the same way terminals can be opened. These may be more convenient for those working with graphical outputs, as shown here where one is used to run `make_plot.py` in the example Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:35 +msgid "![binder_notebook](../../figures/binder_notebook.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:37 +msgid "If R is installed in a Binder the dropdown menu will show the options to open R Jupyter notebooks and RStudio sessions in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:41 +# header +msgid "### Disambiguation" +msgstr "" + +#: reproducible_environments/04/binder.md:43 +msgid "In this section there are a number of related terms, which will be outlined here for clarity:" +msgstr "" + +#: reproducible_environments/04/binder.md:45 +# unordered list +msgid "- Binder: A sharable version of a project that can be viewed and interacted within a reproducible computational environment via a web browser." +msgstr "" + +#: reproducible_environments/04/binder.md:46 +# unordered list +msgid "- BinderHub: A service which generates Binders. The most widely-used is [mybinder.org](https://mybinder.org), which is maintained by the Binder team. It is possible to create other BinderHubs which can support more specialised configurations. One such configuration could include authentication to enable private repositories to be shared amongst close collaborators." +msgstr "" + +#: reproducible_environments/04/binder.md:47 +# unordered list +msgid "- [mybinder.org](https://mybinder.org): A public and free BinderHub. Because it is public you should not use it if your project requires any personal or sensitive information (such as passwords)." +msgstr "" + +#: reproducible_environments/04/binder.md:48 +# unordered list +msgid "- Binderize: To make a Binder of a project." +msgstr "" + +#: reproducible_environments/04/binder.md:50 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:52 +# header +msgid "### Creating a Binder for a project" +msgstr "" + +#: reproducible_environments/04/binder.md:54 +msgid "Creating a Binderized version of a project involves three key steps which will be explained in this section:" +msgstr "" + +#: reproducible_environments/04/binder.md:56 +# ordered list +msgid "1. Specify the computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:57 +# ordered list +msgid "2. Put the project files somewhere publicly available (we will describe how to do this with GitHub)" +msgstr "" + +#: reproducible_environments/04/binder.md:58 +# ordered list +msgid "3. Generate a link to a Binder of the project" +msgstr "" + +#: reproducible_environments/04/binder.md:60 +msgid "For a list of sample repositories for use with Binder, see the [Sample Binder Repositories](https://mybinder.readthedocs.io/en/latest/sample_repos.html) page." +msgstr "" + +#: reproducible_environments/04/binder.md:62 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:64 +# header +msgid "#### Step 1: Specify your computational environment" +msgstr "" + +#: reproducible_environments/04/binder.md:66 +msgid "If a project contains no file specifying the computational environment when a Binder is generated the environment will be the Binder default environment, (containing Python 3.6) which may or may not be suitable for the project. However if it does contain a configuration file for the environment then the Binder will be generated with the specified environment. A full list of such files Binder accepts with examples can be found [here](https://mybinder.readthedocs.io/en/latest/config_files.html), but here are some of the key ones, some of which are language-specific:" +msgstr "" + +#: reproducible_environments/04/binder.md:68 +# unordered list +msgid "- environment.yml" +msgstr "" + +#: reproducible_environments/04/binder.md:69 +# unordered list +msgid " - Recall that environment.yml files were discussed in the [Package management systems](#Package_management_systems) section." +msgstr "" + +#: reproducible_environments/04/binder.md:70 +# unordered list +msgid "- Dockerfile" +msgstr "" + +#: reproducible_environments/04/binder.md:71 +# unordered list +msgid " - Dockerfiles will be discussed in the [Containers](#Containers_section) section, so will not be discussed further here." +msgstr "" + +#: reproducible_environments/04/binder.md:72 +# unordered list +msgid "- apt.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:73 +# unordered list +msgid " - Dependencies that would typically installed via commands such as `sudo apt-get install package_name` should be listed in an apt.txt file, and will be automatically installed in the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:74 +# unordered list +msgid " - For example if a project uses Latex the apt.txt file should read" +msgstr "" + +#: reproducible_environments/04/binder.md:75 +# code block +msgid " ```\n" +" texlive-latex-base\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:78 +msgid " to install the base Latex package." +msgstr "" + +#: reproducible_environments/04/binder.md:79 +# unordered list +msgid "- default.nix" +msgstr "" + +#: reproducible_environments/04/binder.md:80 +# unordered list +msgid " - For those that use the [package management system](#Package_management_systems) Nix a default.nix file can be a convenient way to capture their environment." +msgstr "" + +#: reproducible_environments/04/binder.md:81 +# unordered list +msgid "- requirements.txt (Python)" +msgstr "" + +#: reproducible_environments/04/binder.md:82 +# unordered list +msgid " - For Python users a requirements.txt file can be used to list dependent packages." +msgstr "" + +#: reproducible_environments/04/binder.md:83 +# unordered list +msgid " - For example to have Binder install numpy this file would simply need to read:" +msgstr "" + +#: reproducible_environments/04/binder.md:84 +# code block +msgid " ```\n" +" numpy\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:87 +# unordered list +msgid " - Specific package version can also be specified using an `==`, for example to have Binder install numpy version 1.14.5 then the file would be" +msgstr "" + +#: reproducible_environments/04/binder.md:88 +# code block +msgid " ```\n" +" numpy==1.14.5\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:91 +# unordered list +msgid " - The requirement.txt file does not need to be hand written. Running the command `pip freeze > requirements.txt` will output a requirements.txt file that fully defines the Python environment." +msgstr "" + +#: reproducible_environments/04/binder.md:92 +# unordered list +msgid "- runtime.txt" +msgstr "" + +#: reproducible_environments/04/binder.md:93 +# unordered list +msgid " - Used to specify a particular version of Python of R for the Binder to use." +msgstr "" + +#: reproducible_environments/04/binder.md:94 +# unordered list +msgid " - To specify which version of R to use specify find the date it was captured on [MRAN](https://mran.microsoft.com/documents/rro/reproducibility) and include it in the runtime.txt file as" +msgstr "" + +#: reproducible_environments/04/binder.md:95 +# code block +msgid " ```\n" +" r---
\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:98 +# unordered list +msgid " - To specify a version of Python, similarly state the version in this file. For example to use Python 2.7 the file would need to read" +msgstr "" + +#: reproducible_environments/04/binder.md:99 +# code block +msgid " ```\n" +" python-2.7\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:102 +# unordered list +msgid "- install.R or DESCRIPTION (R/RStudio)" +msgstr "" + +#: reproducible_environments/04/binder.md:103 +# unordered list +msgid " - An install.R file lists the packages to be installed, for example to install the package tibble in the Binder:" +msgstr "" + +#: reproducible_environments/04/binder.md:104 +# code block +msgid " ```\n" +" install.packages(\"tibble\")\n" +" ```" +msgstr "" + +#: reproducible_environments/04/binder.md:107 +# unordered list +msgid " - [DESCRIPTION files](https://cran.r-project.org/doc/manuals/r-release/R-exts.html#The-DESCRIPTION-file) are more typically used in the R community for dependency management." +msgstr "" + +#: reproducible_environments/04/binder.md:109 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:111 +# header +msgid "#### Step 2: Put your code on GitHub" +msgstr "" + +#: reproducible_environments/04/binder.md:113 +msgid "GitHub is discussed at length in the chapter on version control, which you should refer to if you wish to understand more about this step. In this chapter we will give the briefest possible explanation. GitHub is a very widely used platform where you can make \"repositories\", and upload code, documentation, or any other files into them. To complete this step:" +msgstr "" + +#: reproducible_environments/04/binder.md:115 +# ordered list +msgid "1. Make an account on [GitHub](https://github.com/)." +msgstr "" + +#: reproducible_environments/04/binder.md:116 +# ordered list +msgid "2. Create a repository for the project you wish to make a Binder of." +msgstr "" + +#: reproducible_environments/04/binder.md:117 +# ordered list +msgid "3. Upload your project files (including the file you have created to specify your computational environment) to the repository and save (\"commit\" in the vocabulary of GitHub) them there." +msgstr "" + +#: reproducible_environments/04/binder.md:119 +msgid "Again, if you are unable to complete these steps refer to the chapter on version control for a fuller explanation." +msgstr "" + +#: reproducible_environments/04/binder.md:121 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:123 +# header +msgid "#### Step 3: Generate a link to a Binder of your project" +msgstr "" + +#: reproducible_environments/04/binder.md:125 +msgid "Head to [https://mybinder.org](https://mybinder.org). You'll see a form that asks you to specify a repository for [mybinder.org](https://mybinder.org) to build. In the first field, paste the URL of the project's GitHub repository. It'll look something like this: `https://github.com//`" +msgstr "" + +#: reproducible_environments/04/binder.md:127 +msgid "![mybinder_gen_link](../../figures/mybinder_gen_link.png)" +msgstr "" + +#: reproducible_environments/04/binder.md:129 +msgid "As you can see there are additional fields in this form, but these are optional are will not be discussed here." +msgstr "" + +#: reproducible_environments/04/binder.md:131 +msgid "Once the URL to the project to be Binderized is supplied two fields will be automatically populated on the screen depicted above:" +msgstr "" + +#: reproducible_environments/04/binder.md:133 +# unordered list +msgid "- The \"Copy the URL below and share your Binder with others\" field, which provides a link to the Binder which can be copied and shared by you." +msgstr "" + +#: reproducible_environments/04/binder.md:134 +# unordered list +msgid "- The \"Copy the text below, then paste into your README to show a binder badge\" field, which as described can be included by you in GitHub to create a button that allows anyone that accesses your project on GitHub to launch the Binder." +msgstr "" + +#: reproducible_environments/04/binder.md:136 +msgid "Finally, click the launch button. This will ask [mybinder.org](https://mybinder.org) to build the environment needed to run the project, note that this may take several minutes. You can click on the \"Build logs\" button to see the logs generated by the build process. These logs are helpful for resolving any issues that cause the build to fail, such as errors in the file defining the computational environment to be generated." +msgstr "" + +#: reproducible_environments/04/binder.md:138 +msgid "Once it has been built the Binder will be automatically launched, again this may take some time." +msgstr "" + +#: reproducible_environments/04/binder.md:140 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:142 +# header +msgid "### Including data in a Binder" +msgstr "" + +#: reproducible_environments/04/binder.md:144 +msgid "There are a few ways to make data available in your Binder. Which is the best one depends on how big your data is and your preferences for sharing data. Note that the more data that is included include the longer it will take for a Binder to launch. Data also takes up storage space which must be paid for, so it is good to be considerate and minimise the data you include, especially on the publicly provided [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/04/binder.md:146 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:148 +# header +msgid "#### Small public files" +msgstr "" + +#: reproducible_environments/04/binder.md:150 +msgid "The simplest approach for small data files that are public is to add them directly to your GitHub repository, i.e to include them along with the rest of your project files in the Binder. This works well and is reasonable for files with sizes up to maybe 10MB." +msgstr "" + +#: reproducible_environments/04/binder.md:152 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:154 +# header +msgid "#### Medium public files" +msgstr "" + +#: reproducible_environments/04/binder.md:156 +msgid "For medium sized files, a few 10s of megabytes to a few hundred megabytes, find some other place online to store them and make sure they are publicly available. Then add a file named postBuild (which is a shell script so the first line must be `#!/bin/bash`) to your project files. In the postBuild file add a single line reading `wget -q -O name_of_your_file link_to_your_file`." +msgstr "" + +#: reproducible_environments/04/binder.md:158 +msgid "The postBuild file is used to execute commands when the files to produce the Binder are being generated. In this case it can be used to download your data into the files used to launch the binder." +msgstr "" + +#: reproducible_environments/04/binder.md:160 +msgid "" +msgstr "" + +#: reproducible_environments/04/binder.md:162 +# header +msgid "#### Large public files" +msgstr "" + +#: reproducible_environments/04/binder.md:164 +msgid "The best option for large files is to use a library specific to the data format to stream the data as you are using it. There are a few restrictions on outgoing traffic from your Binder that are imposed by the team operating [mybinder.org](https://mybinder.org). Currently only connections to HTTP and Git are allowed. This comes up when people want to use FTP sites to fetch data. For security reasons FTP is not allowed on [mybinder.org](https://mybinder.org)." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:3 +# header +msgid "## Virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:7 +# header +msgid "### What are virtual machines?" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:9 +msgid "Virtual machines (VMs) essentially package a whole computer as an app that can be run. As an example see the figure below which shows a windows laptop (note the windows search button in the lower left corner) running a virtual ubuntu machine (note the terminal outputting the operating system). The machine running the VM is called the \"host machine\". Using software like [VirtualBox](https://www.virtualbox.org/) or [Vagrant](https://www.vagrantup.com/), a user can create and run any number of VMs. As you could probably guess, having several VMs running at once can be a drain on memory, so just because you can run several at once doesn’t mean you should." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:11 +msgid "![virtual_machine](../../figures/virtual_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:13 +msgid "Users can download, install, backup and destroy VMs at will, which is part of what makes them an attractive tool for sharing reproducible research. Research often requires specific pieces of software or system settings. If a researcher wishes to reproduce another's work on their own computer making the necessary changes to their environment to run the project may impact their own work. For example near the very start of this chapter it was [described](#How_this_will_help_you_why_this_is_useful) how using a different version of Python can lead to unexpected changes in the results of an analysis. Say a researcher installs an updated version of Python to replicate an analysis because the analysis requires features only present in the updated version. By doing so they put their own work at risk. VMs remove that risk; any tools downloaded or settings changed will only impact the VM, keeping the reproducer's research safe. If they do inadvertently break something in the VM, they can just delete it and make another one. They are effectively a quarantined area." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:15 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:17 +# header +msgid "### Using virtual machines for reproducible research" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:19 +msgid "Virtual machines can be shared by exporting them as single files. Another researcher can then import that file using their own virtualisation software like [VirtualBox](https://www.virtualbox.org/) and open up a copy of the VM which will contain all the software files and settings put in place by the person that made the VM. Therefore in practice they will have a working version of the project without the pain of setting it up themselves." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:21 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:23 +# header +msgid "#### Setting up a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:25 +msgid "First choose a tool for generating VMs. Here the widely-used [VirtualBox](https://www.virtualbox.org/) is chosen. Download and install it on your system. To create a new machine click \"New\" in the top left. A window will pop up where you can enter a name for the machine and select what operating system and version of the operating system to use. In the figure below a machine called demo_VM running ubuntu is being created:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:27 +msgid "![VM_create_machine](../../figures/VM_create_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:29 +msgid "As you click through you can adjust other features of the machine to be created such as how much memory it should have access to. The default options are suitable for most purposes, but this process permits customisation." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:31 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:33 +# header +msgid "#### Starting a virtual machine" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:35 +msgid "To start a virtual machine simply select the machine from the list of VMs on the left, and click the green \"start\" arrow at the top:" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:37 +msgid "![VM_start_machine](../../figures/VM_start_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:39 +msgid "" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:41 +# header +msgid "#### Sharing virtual virtual machines" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:43 +msgid "A researcher can do work on their VM, and then export the whole thing. To export a virtual machine click \"File\" in the top left and then \"Export\". This will export the VM as a single file which can be shared like any other." +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:45 +msgid "![VM_export_machine](../../figures/VM_export_machine.png)" +msgstr "" + +#: reproducible_environments/05/virtual-machines.md:47 +msgid "Someone that has access to this file and VirtualBox installed just needs to click \"File\" in the top left and then \"Import\" and select that file. Once it is imported they can start the VM as described before by selecting it from the menu clicking the green start arrow at the top." +msgstr "" + +#: reproducible_environments/06/containers.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:3 +# header +msgid "## Containers" +msgstr "" + +#: reproducible_environments/06/containers.md:5 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:7 +# header +msgid "### Why Containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:9 +msgid "Even for moderately complex projects, the size of the software dependency stack can be huge. Take for example a simple" +msgstr "" + +#: reproducible_environments/06/containers.md:10 +msgid "pipeline to build a pdf report for an analysis scripted in R using Rmarkdown. To make this reproducible, not only (i)" +msgstr "" + +#: reproducible_environments/06/containers.md:11 +msgid "the respective R packages need to be installed and (ii) the R version needs to be the same, but also (iii) the versions" +msgstr "" + +#: reproducible_environments/06/containers.md:12 +msgid "of pandoc and LaTeX need to be exaclty the same as during runtime." +msgstr "" + +#: reproducible_environments/06/containers.md:14 +msgid "Instead of trying to resolve these dependencies via a package manager (such as conda) which also depends on all required" +msgstr "" + +#: reproducible_environments/06/containers.md:15 +msgid "software being available in a single package manager, it might be easier to simply create a snapshot of the entire" +msgstr "" + +#: reproducible_environments/06/containers.md:16 +msgid "computing environment including all dependencies. These computing environments are then self-contained, hence the name" +msgstr "" + +#: reproducible_environments/06/containers.md:17 +msgid "'containers'." +msgstr "" + +#: reproducible_environments/06/containers.md:19 +# header +msgid "### What are containers?" +msgstr "" + +#: reproducible_environments/06/containers.md:21 +msgid "Containers allow a researcher to package up a project with all of the parts it needs, such as libraries, dependencies," +msgstr "" + +#: reproducible_environments/06/containers.md:22 +msgid "and system settings and ship it all out as one package. Anyone can then open up a container and work within it, viewing" +msgstr "" + +#: reproducible_environments/06/containers.md:23 +msgid "and interacting with the project as if the machine they are accessing it from is identical to the machine specified in" +msgstr "" + +#: reproducible_environments/06/containers.md:24 +msgid "the container - regardless of what their computational environment _actually_ is. They are designed to make it easier to" +msgstr "" + +#: reproducible_environments/06/containers.md:25 +msgid "transfer projects between very different environments." +msgstr "" + +#: reproducible_environments/06/containers.md:27 +msgid "In a way, containers behave like a virtual machine. To the outside world, they look like their own complete system. But" +msgstr "" + +#: reproducible_environments/06/containers.md:28 +msgid "unlike a virtual machine, rather than creating a whole virtual operating system plus all the software and tools" +msgstr "" + +#: reproducible_environments/06/containers.md:29 +msgid "typically packaged with one, containers only contain the individual components they need in order to operate the project" +msgstr "" + +#: reproducible_environments/06/containers.md:30 +msgid "they contain. This gives a significant performance boost and reduces the size of the application." +msgstr "" + +#: reproducible_environments/06/containers.md:32 +msgid "Containers are particularly useful way for reproducing research which relies on software to be configured in a certain" +msgstr "" + +#: reproducible_environments/06/containers.md:33 +msgid "way, and/or which makes use of libraries that vary between (or don't exist on) different systems. In summary containers" +msgstr "" + +#: reproducible_environments/06/containers.md:34 +msgid "are a more robust way of sharing reproducible research than, for instance, package management systems or Binder because" +msgstr "" + +#: reproducible_environments/06/containers.md:35 +msgid "they reproduce the entire system used for the research, not just the packages explicitly used by it. Their major" +msgstr "" + +#: reproducible_environments/06/containers.md:36 +msgid "downside is that due to their greater depth they are conceptually more difficult to grasp and produce than many other" +msgstr "" + +#: reproducible_environments/06/containers.md:37 +msgid "methods of replicating computational environments." +msgstr "" + +#: reproducible_environments/06/containers.md:39 +msgid "Ben Corrie give as reasonably accessible overview on core concepts in" +msgstr "" + +#: reproducible_environments/06/containers.md:40 +msgid "['What is a container?'](https://www.youtube.com/watch?v=EnJ7qX9fkcU)." +msgstr "" + +#: reproducible_environments/06/containers.md:42 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:44 +# header +msgid "### What are images?" +msgstr "" + +#: reproducible_environments/06/containers.md:46 +msgid "Images are the files used to generate containers. Humans don't make images, they write the recipes to generate images." +msgstr "" + +#: reproducible_environments/06/containers.md:47 +msgid "Containers are then identical copies instantiated from images." +msgstr "" + +#: reproducible_environments/06/containers.md:49 +msgid "Think of it like this:" +msgstr "" + +#: reproducible_environments/06/containers.md:51 +# unordered list +msgid "- A recipe file a human writes contains all the steps to generate a working version of the project and its computational" +msgstr "" + +#: reproducible_environments/06/containers.md:52 +msgid " environment, but no actual materials. Think of this as like a blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:53 +# unordered list +msgid "- Building an image takes that recipe and using it assembles all the packages, software libraries, and configurations" +msgstr "" + +#: reproducible_environments/06/containers.md:54 +msgid " needed to make the fully fledged project and environment and bundles them up in a condensed lump. Think of images like" +msgstr "" + +#: reproducible_environments/06/containers.md:55 +msgid " a bit of flat pack furniture made using the blueprint." +msgstr "" + +#: reproducible_environments/06/containers.md:56 +# unordered list +msgid "- Containers take that image and assemble a full working version of the project and the environment needed to run it." +msgstr "" + +#: reproducible_environments/06/containers.md:57 +msgid " Think of this as assembling the bit of flat pack furniture." +msgstr "" + +#: reproducible_environments/06/containers.md:59 +msgid "So if a researcher wants to allow others to reproduce their work they would need to write a recipe file, and use it to" +msgstr "" + +#: reproducible_environments/06/containers.md:60 +msgid "build an image of their project. They can then share this image file with anyone who wants to replicate their work. That" +msgstr "" + +#: reproducible_environments/06/containers.md:61 +msgid "person can then use the image to generate a container containing a working version of the project." +msgstr "" + +#: reproducible_environments/06/containers.md:63 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:65 +# header +msgid "### What is Docker?" +msgstr "" + +#: reproducible_environments/06/containers.md:67 +msgid "There are a number of different tools available for creating and working with containers. We will focus on Docker, which" +msgstr "" + +#: reproducible_environments/06/containers.md:68 +msgid "is widely used, but be aware that others such as Singularity also exist. Singularity is sometimes preferred for use on" +msgstr "" + +#: reproducible_environments/06/containers.md:69 +msgid "HPC systems as it does not need `sudo` permissions to be run, while Docker does." +msgstr "" + +#: reproducible_environments/06/containers.md:71 +msgid "In Docker the recipe files used to generate images are known as Dockerfiles, and should be named \"Dockerfile\"." +msgstr "" + +#: reproducible_environments/06/containers.md:73 +msgid "[DockerHub](https://hub.docker.com/) hosts a great many pre-made images which can be downloaded and build upon, such as" +msgstr "" + +#: reproducible_environments/06/containers.md:74 +msgid "[images](https://hub.docker.com/_/ubuntu) of Ubuntu machines. This makes the process of writing Dockerfiles relatively" +msgstr "" + +#: reproducible_environments/06/containers.md:75 +msgid "easy since users very rarely need to start from scratch, they can just customise existing images. However, this does" +msgstr "" + +#: reproducible_environments/06/containers.md:76 +msgid "leave a user vulnerable to similar security issues as were described in the section on [YAML files](#Security_issues):" +msgstr "" + +#: reproducible_environments/06/containers.md:78 +# unordered list +msgid "- It is possible to include malicious code in Docker images" +msgstr "" + +#: reproducible_environments/06/containers.md:79 +# unordered list +msgid "- It is possible for people producing images to unknowingly include software in them with security vulnerabilities" +msgstr "" + +#: reproducible_environments/06/containers.md:81 +msgid "[This](https://opensource.com/business/14/7/docker-security-selinux) article goes deeper into the potential security" +msgstr "" + +#: reproducible_environments/06/containers.md:82 +msgid "vulnerabilities of containers and here is a" +msgstr "" + +#: reproducible_environments/06/containers.md:83 +msgid "[detailed breakdown](https://opensource.com/business/14/9/security-for-docker) of security features currently within" +msgstr "" + +#: reproducible_environments/06/containers.md:84 +msgid "Docker, and how they function. The best advice for using images built by others is as standard- only download and run" +msgstr "" + +#: reproducible_environments/06/containers.md:85 +msgid "something on your machine if it comes from a trusted source. DockerHub has \"official image\" badges for commonly used," +msgstr "" + +#: reproducible_environments/06/containers.md:86 +msgid "verified images as shown here:" +msgstr "" + +#: reproducible_environments/06/containers.md:88 +msgid "![Docker_official_image](../../figures/docker_official_image.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:90 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:92 +# header +msgid "### Installing Docker" +msgstr "" + +#: reproducible_environments/06/containers.md:94 +msgid "Installers for Docker on a variety of different systems are available [here](https://docs.docker.com/install/). Detailed" +msgstr "" + +#: reproducible_environments/06/containers.md:95 +msgid "installation instructions are also available for a variety of operating systems such as" +msgstr "" + +#: reproducible_environments/06/containers.md:96 +msgid "[ubuntu](https://docs.docker.com/install/linux/docker-ce/ubuntu/)," +msgstr "" + +#: reproducible_environments/06/containers.md:97 +msgid "[debian](https://docs.docker.com/install/linux/docker-ce/debian/)," +msgstr "" + +#: reproducible_environments/06/containers.md:98 +msgid "[Macs](https://docs.docker.com/docker-for-mac/install/), and" +msgstr "" + +#: reproducible_environments/06/containers.md:99 +msgid "[Windows](https://docs.docker.com/docker-for-windows/install/)." +msgstr "" + +#: reproducible_environments/06/containers.md:101 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:103 +# header +msgid "### Key commands" +msgstr "" + +#: reproducible_environments/06/containers.md:105 +msgid "Here are a few key commands for creating and working with containers." +msgstr "" + +#: reproducible_environments/06/containers.md:107 +# unordered list +msgid "- To build an image from a Dockerfile go to the directory where the Dockerfile is and run:" +msgstr "" + +#: reproducible_environments/06/containers.md:108 +# code block +msgid " ```\n" +" sudo docker build tag=name_to_give_image .\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:111 +# unordered list +msgid "- To list the images on your system use" +msgstr "" + +#: reproducible_environments/06/containers.md:112 +# code block +msgid " ```\n" +" sudo docker image ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:115 +# unordered list +msgid "- To remove an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:116 +# code block +msgid " ```\n" +" sudo docker rmi image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:119 +# unordered list +msgid "- To open a container from an image run" +msgstr "" + +#: reproducible_environments/06/containers.md:120 +# code block +msgid " ```\n" +" sudo docker run -i -t image_name\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:123 +msgid " The `-i -t` flags automatically open up an interactive terminal within the container so you can view and interact with" +msgstr "" + +#: reproducible_environments/06/containers.md:124 +msgid " the project files." +msgstr "" + +#: reproducible_environments/06/containers.md:125 +# unordered list +msgid "- To exit an interactive terminal use the command `exit`." +msgstr "" + +#: reproducible_environments/06/containers.md:126 +# unordered list +msgid "- To get a list of active containers with IDs run" +msgstr "" + +#: reproducible_environments/06/containers.md:127 +# code block +msgid " ```\n" +" sudo docker container ls\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:130 +# unordered list +msgid "- There are also three main commands used for changing the status of containers:" +msgstr "" + +#: reproducible_environments/06/containers.md:131 +# unordered list +msgid " - Pausing suspends the process running the container." +msgstr "" + +#: reproducible_environments/06/containers.md:132 +# code block +msgid " ```\n" +" sudo docker container_ID pause\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:135 +msgid " Containers can be unpaused by replacing `pause` with `unpause`." +msgstr "" + +#: reproducible_environments/06/containers.md:136 +# unordered list +msgid " - Stopping a container terminates the process running it. A container must be stopped before it can be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:137 +# code block +msgid " ```\n" +" sudo docker container_ID stop\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:140 +msgid " A stopped container can be restarted by replacing `stop` with `restart`." +msgstr "" + +#: reproducible_environments/06/containers.md:141 +# unordered list +msgid " - If `stop` does not work containers can be killed using" +msgstr "" + +#: reproducible_environments/06/containers.md:142 +# code block +msgid " ```\n" +" sudo docker container_ID kill\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:145 +# unordered list +msgid "- To remove a container run" +msgstr "" + +#: reproducible_environments/06/containers.md:146 +# code block +msgid " ```\n" +" sudo docker rm container_ID\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:150 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:152 +# header +msgid "### Writing Dockerfiles" +msgstr "" + +#: reproducible_environments/06/containers.md:154 +msgid "Let's go through the anatomy of a very simple Dockerfile:" +msgstr "" + +#: reproducible_environments/06/containers.md:156 +# code block +msgid "```\n" +"# Step 1: Set up the computational environment\n" +"\n" +"# Set the base image\n" +"FROM ubuntu\n" +"\n" +"# Install packages needed to run the project\n" +"RUN apt-get update\n" +"RUN apt-get install sudo\n" +"RUN sudo apt-get update\n" +"RUN sudo apt-get install -y python3.7\n" +"RUN sudo apt-get install -y python3-pip\n" +"RUN pip3 install numpy\n" +"\n" +"#-----------------------\n" +"\n" +"# Step 2: Include the project files in the image\n" +"\n" +"# Make a directory called \"project\" to hold the project files\n" +"RUN mkdir project\n" +"\n" +"# Copy files from the project_files directory on the machine building the image\n" +"# into the \"project\" directory created by the previous line of code\n" +"COPY project_files/* project/\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:182 +msgid "This looks complicated, but most of the lines in this example are comments (which are preceded by `#`s), There are only" +msgstr "" + +#: reproducible_environments/06/containers.md:183 +msgid "nine lines of actual code. The first of these is a `FROM` statement specifying a base image. All Dockerfiles require a" +msgstr "" + +#: reproducible_environments/06/containers.md:184 +msgid "FROM, even if it's just `FROM SCRATCH`. All the following commands in a Dockerfile build upon the base image to make a" +msgstr "" + +#: reproducible_environments/06/containers.md:185 +msgid "functioning version of the researcher's project." +msgstr "" + +#: reproducible_environments/06/containers.md:187 +msgid "It is worth spending time carefully choosing an appropriate base image as doing do can reduce the amount of work" +msgstr "" + +#: reproducible_environments/06/containers.md:188 +msgid "involved in writing a Dockerfile dramatically. For example a collection of images with the R programming language" +msgstr "" + +#: reproducible_environments/06/containers.md:189 +msgid "included in them can be found [here](https://github.com/rocker-org/rocker-versioned). If a project makes use of R it is" +msgstr "" + +#: reproducible_environments/06/containers.md:190 +msgid "convenient to use one of these as a base image rather than spend time writing commands in your Dockerfile to install R." +msgstr "" + +#: reproducible_environments/06/containers.md:192 +msgid "The biggest block of lines comes next, it's a series of `RUN` statements, which run shell command when building the" +msgstr "" + +#: reproducible_environments/06/containers.md:193 +msgid "image. In this block they are used to install the software necessary to run the project. Run commands can also be" +msgstr "" + +#: reproducible_environments/06/containers.md:194 +msgid "chained as follows if desired:" +msgstr "" + +#: reproducible_environments/06/containers.md:196 +# code block +msgid "```\n" +"RUN command_to_do_thing_1 \\\n" +" && command_to_do_thing_2 \\\n" +" && command_to_do_thing_3 \\\n" +" && command_to_do_thing_4\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:203 +msgid "Another RUN statement is used to run the shell command `RUN mkdir project` which makes a directory called project in the" +msgstr "" + +#: reproducible_environments/06/containers.md:204 +msgid "container to host the files related to this project." +msgstr "" + +#: reproducible_environments/06/containers.md:206 +msgid "Finally the `COPY` command is used to copy the project files from the machine building the image into the image itself." +msgstr "" + +#: reproducible_environments/06/containers.md:207 +msgid "The syntax of this command is `COPY file_to_copy location_in_container_to_copy_to`. In this example all the files in the" +msgstr "" + +#: reproducible_environments/06/containers.md:208 +msgid "\"project_files\" directory are included in the \"project\" file in the container. Note that you can only copy files from" +msgstr "" + +#: reproducible_environments/06/containers.md:209 +msgid "the directory where the Dockerfile is located, or subdirectories within it (in the example given here the project_files" +msgstr "" + +#: reproducible_environments/06/containers.md:210 +msgid "subdirectory)." +msgstr "" + +#: reproducible_environments/06/containers.md:212 +msgid "The `ADD` command has the same capabilities as `COPY`, but it can also be used to add files not on the machine building" +msgstr "" + +#: reproducible_environments/06/containers.md:213 +msgid "the image. For example it can be used to include files hosted online by following ADD with a URL to the file. It is good" +msgstr "" + +#: reproducible_environments/06/containers.md:214 +msgid "practice to use `COPY` except where `ADD` is specifically required as the term `COPY` is more explicit about what is" +msgstr "" + +#: reproducible_environments/06/containers.md:215 +msgid "being done." +msgstr "" + +#: reproducible_environments/06/containers.md:217 +msgid "Here's what happens if a container is opened from an image called book_example built from the example above:" +msgstr "" + +#: reproducible_environments/06/containers.md:219 +msgid "![container_example](../../figures/container_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:221 +msgid "As you can see the directory \"project\" has been created, and if we look inside the project files \"analysis.py\" and" +msgstr "" + +#: reproducible_environments/06/containers.md:222 +msgid "\"data.csv\" have been copied into it. Because the software required for the project has already been included by the" +msgstr "" + +#: reproducible_environments/06/containers.md:223 +msgid "Dockerfile in the image the \"analysis.py\" script runs without any further software needing to be installed." +msgstr "" + +#: reproducible_environments/06/containers.md:225 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:227 +# header +msgid "#### WORKDIR" +msgstr "" + +#: reproducible_environments/06/containers.md:229 +msgid "This command can be used in Dockerfiles to change the current working directory. Commands that follow this in the" +msgstr "" + +#: reproducible_environments/06/containers.md:230 +msgid "Dockerfile will be applied within the new working directory unless/until another WORKDIR changes the working directory." +msgstr "" + +#: reproducible_environments/06/containers.md:231 +msgid "When a container is opened with an interactive terminal the terminal will open in the final working directory. Here's a" +msgstr "" + +#: reproducible_environments/06/containers.md:232 +msgid "simple example of a Dockerfile that uses `WORKDIR`, and the container it generates." +msgstr "" + +#: reproducible_environments/06/containers.md:234 +# code block +msgid "```\n" +"# Basic setup\n" +"FROM ubuntu\n" +"RUN apt-get update\n" +"\n" +"# Make a directory called A\n" +"RUN mkdir A\n" +"\n" +"# Make the working directory A\n" +"WORKDIR A\n" +"\n" +"# Make two directories, one called B_1 and one called B_2\n" +"RUN mkdir B_1\n" +"RUN mkdir B_2\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:250 +msgid "![workdir_example](../../figures/workdir_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:252 +msgid "Directories B_1 and B_2 have been created within directory A." +msgstr "" + +#: reproducible_environments/06/containers.md:254 +msgid "WORKDIR should be used whenever changing directories is necessary when building an image. It may be tempting to use" +msgstr "" + +#: reproducible_environments/06/containers.md:255 +msgid "`RUN cd directory_name` instead as this syntax will be more familiar to those that commonly work via the command line," +msgstr "" + +#: reproducible_environments/06/containers.md:256 +msgid "but this can lead to errors. After each `RUN` statement in a Dockerfile the image is saved, any following commands are" +msgstr "" + +#: reproducible_environments/06/containers.md:257 +msgid "applied to the image anew. As an example here is what happens in the above example if the `WORKDIR A` line is swapped" +msgstr "" + +#: reproducible_environments/06/containers.md:258 +msgid "for `RUN cd A`" +msgstr "" + +#: reproducible_environments/06/containers.md:260 +msgid "![cd_example](../../figures/cd_example.png)" +msgstr "" + +#: reproducible_environments/06/containers.md:262 +msgid "All the directories have are in the top level in this case, rather than B_1 and B_2 being inside A. This is because the" +msgstr "" + +#: reproducible_environments/06/containers.md:263 +msgid "image was restarted after the `RUN cd A` command and opened at the top (root) level by default, so that is where the" +msgstr "" + +#: reproducible_environments/06/containers.md:264 +msgid "`mkdir B_1` and `mkdir B_2` commands took effect." +msgstr "" + +#: reproducible_environments/06/containers.md:266 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:268 +# header +msgid "#### Other commands" +msgstr "" + +#: reproducible_environments/06/containers.md:270 +msgid "Other commands that are sometimes used in Dockerfiles include:" +msgstr "" + +#: reproducible_environments/06/containers.md:272 +# unordered list +msgid "- `CMD`: This is used to run commands as soon as the container is opened. To clarify this is different to RUN commands" +msgstr "" + +#: reproducible_environments/06/containers.md:273 +msgid " which are commands run as part of _setting up_ a container. For example to have a welcome message when a container is" +msgstr "" + +#: reproducible_environments/06/containers.md:274 +msgid " opened from the image CMD could be used as follows:" +msgstr "" + +#: reproducible_environments/06/containers.md:275 +# code block +msgid " ```\n" +" CMD [\"echo\",\"Welcome! You just opened this container!\"]\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:278 +msgid " It's good practice to use CMD for any commands that need to be run before someone starts working in the container" +msgstr "" + +#: reproducible_environments/06/containers.md:279 +msgid " instead of forcing users to run them themselves (and trusting that they will even know that they need to)." +msgstr "" + +#: reproducible_environments/06/containers.md:280 +# unordered list +msgid "- `VOLUMES`: These will be discussed [later](#Volumes)." +msgstr "" + +#: reproducible_environments/06/containers.md:281 +# unordered list +msgid "- `MAINTAINER`: information regarding the person that wrote the Dockerfile. Typically included at the top of a" +msgstr "" + +#: reproducible_environments/06/containers.md:282 +msgid " Dockerfile." +msgstr "" + +#: reproducible_environments/06/containers.md:283 +# unordered list +msgid "- `EXPOSE`: This includes ports that should be exposed, this is more relevant to people using Docker to share web apps." +msgstr "" + +#: reproducible_environments/06/containers.md:284 +# unordered list +msgid "- `USER`: Change the user that a command is run as (useful for dropping privileges)." +msgstr "" + +#: reproducible_environments/06/containers.md:286 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:288 +# header +msgid "### Building images and .dockerignore files" +msgstr "" + +#: reproducible_environments/06/containers.md:290 +msgid "As mentioned in the [key commands](#Key_commands) section, to build an image open a terminal in the same directory as" +msgstr "" + +#: reproducible_environments/06/containers.md:291 +msgid "the Dockerfile to be used and run" +msgstr "" + +#: reproducible_environments/06/containers.md:293 +# code block +msgid "```\n" +"sudo docker build tag=name_to_give_image .\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:297 +msgid "When an image is built everything in the Dockerfile's directory and below (this is called the \"context\") is sent to the" +msgstr "" + +#: reproducible_environments/06/containers.md:298 +msgid "Docker daemon to build the image. The deamon uses the Dockerfile and its context to build the image. If the context" +msgstr "" + +#: reproducible_environments/06/containers.md:299 +msgid "contains many large files which aren't needed for building the image (old datafiles, for example) then it is a waste of" +msgstr "" + +#: reproducible_environments/06/containers.md:300 +msgid "time sending them to the daemon, and doing do can make the process of building an image slow. Files can be excluded from" +msgstr "" + +#: reproducible_environments/06/containers.md:301 +msgid "the context by listing them in a text file called .dockerignore, and it is good practise to do so." +msgstr "" + +#: reproducible_environments/06/containers.md:303 +msgid "The files do not need to be listed individually in the .dockerignore file. Here is an example of the contents of a" +msgstr "" + +#: reproducible_environments/06/containers.md:304 +msgid ".dockerignore file:" +msgstr "" + +#: reproducible_environments/06/containers.md:306 +# code block +msgid "```\n" +"*.jpg\n" +"**/*.png\n" +"data_files/*\n" +"file_to_exclude.txt\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:313 +msgid "This excludes from the context:" +msgstr "" + +#: reproducible_environments/06/containers.md:315 +# unordered list +msgid "- All jpg files in the same directory as the Dockerfile file" +msgstr "" + +#: reproducible_environments/06/containers.md:316 +# unordered list +msgid "- All png files in the same directory as the Dockerfile file _or any subdirectories within it_" +msgstr "" + +#: reproducible_environments/06/containers.md:317 +# unordered list +msgid "- All files within the data_files directory" +msgstr "" + +#: reproducible_environments/06/containers.md:318 +# unordered list +msgid "- The file named \"file_to_exclude.txt\"" +msgstr "" + +#: reproducible_environments/06/containers.md:320 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:322 +# header +msgid "### Sharing images" +msgstr "" + +#: reproducible_environments/06/containers.md:324 +msgid "Docker images can be shared most easily via [DockerHub](https://hub.docker.com/), which requires an account. Say two" +msgstr "" + +#: reproducible_environments/06/containers.md:325 +msgid "researchers, Alice and Bob, are collaborating on a project and Alice wishes to share an image of some of her work with" +msgstr "" + +#: reproducible_environments/06/containers.md:326 +msgid "Bob." +msgstr "" + +#: reproducible_environments/06/containers.md:328 +msgid "To do this Alice must:" +msgstr "" + +#: reproducible_environments/06/containers.md:330 +# unordered list +msgid "- Write a Dockerfile to produce an image of her work" +msgstr "" + +#: reproducible_environments/06/containers.md:331 +# unordered list +msgid "- Build the image. She (being inventive) calls it image_name" +msgstr "" + +#: reproducible_environments/06/containers.md:332 +# unordered list +msgid "- Go to DockerHub and sign up for an account. Say Alice (again, being inventive) chooses the username username_Alice" +msgstr "" + +#: reproducible_environments/06/containers.md:333 +# unordered list +msgid "- Log into DockerHub via the terminal on her machine using `sudo docker login`" +msgstr "" + +#: reproducible_environments/06/containers.md:334 +# unordered list +msgid "- Tag the image of her project on her machine via the command line by supplying the name of the image and using the" +msgstr "" + +#: reproducible_environments/06/containers.md:335 +msgid " pattern `username/image_name:version`, so Alice runs the command:" +msgstr "" + +#: reproducible_environments/06/containers.md:336 +# code block +msgid " ```\n" +" sudo docker tag image_name username_Alice/image_name:version_1\n" +" ```" +msgstr "" + +#: reproducible_environments/06/containers.md:339 +# unordered list +msgid "- Push the image to her DockerHub account using `sudo docker tag push username_Alice/image_name:version_1`" +msgstr "" + +#: reproducible_environments/06/containers.md:340 +# unordered list +msgid "- Alice's image is now online and can be downloaded. Over to Bob..." +msgstr "" + +#: reproducible_environments/06/containers.md:342 +msgid "Bob (assuming he already has Docker installed) can open a container from Alice's image simply by running" +msgstr "" + +#: reproducible_environments/06/containers.md:344 +# code block +msgid "```\n" +"sudo docker run -i -t username_Alice/image_name:version_1\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:348 +msgid "Initially Docker will search for this image on Bob's machine, and when it doesn't find it it will _automatically_ search" +msgstr "" + +#: reproducible_environments/06/containers.md:349 +msgid "DockerHub, download Alice's image, and open the container with Alice's work and environment on Bob's machine." +msgstr "" + +#: reproducible_environments/06/containers.md:351 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:353 +# header +msgid "### Copying files to and from containers" +msgstr "" + +#: reproducible_environments/06/containers.md:355 +msgid "Containers act much like virtual machines, as a result copying files into and out of them is not as trivial as copying" +msgstr "" + +#: reproducible_environments/06/containers.md:356 +msgid "files to different locations within the same computer is." +msgstr "" + +#: reproducible_environments/06/containers.md:358 +msgid "A file can be copied from the machine running a container into the container using:" +msgstr "" + +#: reproducible_environments/06/containers.md:360 +# code block +msgid "```\n" +"sudo docker cp file_name conteriner_ID:path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:364 +msgid "Recall that container IDs can be obtained using `sudo docker container ls`." +msgstr "" + +#: reproducible_environments/06/containers.md:366 +msgid "A file can be copied from within a container to the machine running the container by running the following command on" +msgstr "" + +#: reproducible_environments/06/containers.md:367 +msgid "the machine running the container:" +msgstr "" + +#: reproducible_environments/06/containers.md:369 +# code block +msgid "```\n" +"sudo docker cp conteriner_ID:path_to_file/file_name path_to_where_to_put_file/file_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:373 +msgid "If the second part (the `path_to_where_to_put_file/file_name`) is substituted for a `.` then the file will be copied to" +msgstr "" + +#: reproducible_environments/06/containers.md:374 +msgid "whatever directory the terminal running the command is in." +msgstr "" + +#: reproducible_environments/06/containers.md:376 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:378 +# header +msgid "### Volumes" +msgstr "" + +#: reproducible_environments/06/containers.md:380 +msgid "Every time a container is opened from an image that container is completely new. For example say a container is opened" +msgstr "" + +#: reproducible_environments/06/containers.md:381 +msgid "and work is done within it, files created, changed, deleted and so on. If that container is then closed and the image it" +msgstr "" + +#: reproducible_environments/06/containers.md:382 +msgid "came from is again used to start a container none of that work will be in the new one. It will simply have the starting" +msgstr "" + +#: reproducible_environments/06/containers.md:383 +msgid "state described in the image." +msgstr "" + +#: reproducible_environments/06/containers.md:385 +msgid "This can be a problem if a researcher wants to work in a container over a period of time, but there is a way around this" +msgstr "" + +#: reproducible_environments/06/containers.md:386 +msgid "using \"volumes\". These store work done within a container even after it is closed, and can then be used to load that" +msgstr "" + +#: reproducible_environments/06/containers.md:387 +msgid "work into future containers." +msgstr "" + +#: reproducible_environments/06/containers.md:389 +msgid "To create/use a volume run" +msgstr "" + +#: reproducible_environments/06/containers.md:391 +# code block +msgid "```\n" +"sudo docker run -i -t --mount source=volume_name,target=/target_dirctory image_name\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:395 +msgid "Hopefully you will give your volume a more descriptive name than volume_name. A \"target\" directory is required, only" +msgstr "" + +#: reproducible_environments/06/containers.md:396 +msgid "work within this directory in the container which will be saved in the volume. Once the researcher is done they can" +msgstr "" + +#: reproducible_environments/06/containers.md:397 +msgid "close the container as normal. When they come back to the project and want to continue their work they just need to use" +msgstr "" + +#: reproducible_environments/06/containers.md:398 +msgid "the exact same command as above, and it will load the work contained in volume_name into the new container. It will save" +msgstr "" + +#: reproducible_environments/06/containers.md:399 +msgid "any new work there too." +msgstr "" + +#: reproducible_environments/06/containers.md:401 +msgid "Volume related commands:" +msgstr "" + +#: reproducible_environments/06/containers.md:403 +# unordered list +msgid "- List volumes: `sudo docker volume ls`" +msgstr "" + +#: reproducible_environments/06/containers.md:404 +# unordered list +msgid "- Delete a volume: `sudo docker volume rm volume_name`" +msgstr "" + +#: reproducible_environments/06/containers.md:405 +# unordered list +msgid "- Delete all unattached volumes: `sudo docker volume prune`" +msgstr "" + +#: reproducible_environments/06/containers.md:406 +# unordered list +msgid "- If, when deleting a container a `-v` is included after `rm` in `sudo docker rm container_ID` any volumes associated" +msgstr "" + +#: reproducible_environments/06/containers.md:407 +msgid " with the container will also be deleted." +msgstr "" + +#: reproducible_environments/06/containers.md:409 +msgid "" +msgstr "" + +#: reproducible_environments/06/containers.md:411 +# header +msgid "### Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:413 +# blockquote, which can be cascaded +msgid "> Prerequisites: At present, Singularity only runs on linux systems (for example Ubuntu). If you use, macOS," +msgstr "" + +#: reproducible_environments/06/containers.md:414 +# blockquote, which can be cascaded +msgid "> [Singularity Desktop for macOS](https://www.sylabs.io/singularity-desktop-macos/) is in \"Alpha Preview\" stage." +msgstr "" + +#: reproducible_environments/06/containers.md:416 +msgid "A major drawback of Docker for reproducible research is that it is not intended as a user-space application but as a" +msgstr "" + +#: reproducible_environments/06/containers.md:417 +msgid "tool for server administrators. As such it requires root access to operate. There is, however, no reason why the" +msgstr "" + +#: reproducible_environments/06/containers.md:418 +msgid "execution of an analysis should require root access for the user. This is especially important when computations are" +msgstr "" + +#: reproducible_environments/06/containers.md:419 +msgid "conducted on shared resource like HPC systems where users will never have root access." +msgstr "" + +#: reproducible_environments/06/containers.md:421 +msgid "The [singularity](https://www.sylabs.io/) container software was introduced to address exactly this issue. Singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:422 +msgid "was created with HPC sytems and reproducible research in mind (see [this](https://www.youtube.com/watch?v=DA87Ba2dpNM)" +msgstr "" + +#: reproducible_environments/06/containers.md:423 +msgid "video). It does not require root access to run (only to build container _images_!) and thus enables HPC users to locally" +msgstr "" + +#: reproducible_environments/06/containers.md:424 +msgid "build container images before running analyses, for example, on a high-performance cluster. As an added benefit, this makes it" +msgstr "" + +#: reproducible_environments/06/containers.md:425 +msgid "possible to use almost any software on an HPC system without having to bother admin staff with installing it. In" +msgstr "" + +#: reproducible_environments/06/containers.md:426 +msgid "recognition of the fact that Docker is _the_ most well known containerization approach, singularity aims at maintaining" +msgstr "" + +#: reproducible_environments/06/containers.md:427 +msgid "compatibility with docker containers as much as possible, meaning that singularity can be used to run normal docker containers" +msgstr "" + +#: reproducible_environments/06/containers.md:428 +msgid "(without requiring root access!)." +msgstr "" + +#: reproducible_environments/06/containers.md:430 +msgid "Singularity can be used to run Docker images or extend them by building new images based on docker containers as base" +msgstr "" + +#: reproducible_environments/06/containers.md:431 +msgid "layer. For instance, we could use singularity to spin up a vanilla ubuntu container and getting a shell in it using the" +msgstr "" + +#: reproducible_environments/06/containers.md:432 +msgid "ubuntu docker image via" +msgstr "" + +#: reproducible_environments/06/containers.md:434 +# code block +msgid "```\n" +"singularity shell docker://ubuntu\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:438 +msgid "(type `exit` to leave the interactive shell again)." +msgstr "" + +#: reproducible_environments/06/containers.md:440 +msgid "Just as docker images are built using `Dockerfile` files, singularity containers are built from singularity definition" +msgstr "" + +#: reproducible_environments/06/containers.md:441 +msgid "files. The process and syntax is similar to docker files but there are subtle differences. As a minimal working example," +msgstr "" + +#: reproducible_environments/06/containers.md:442 +msgid "we can build a 'lolcow' container based on the official ubuntu docker container image. Put the following in a" +msgstr "" + +#: reproducible_environments/06/containers.md:443 +msgid "`lolcow.def` file (based on the" +msgstr "" + +#: reproducible_environments/06/containers.md:444 +msgid "[Singularity documentation](https://www.sylabs.io/guides/3.2/user-guide/build_a_container.html)):" +msgstr "" + +#: reproducible_environments/06/containers.md:446 +# code block +msgid "```\n" +"Bootstrap: docker\n" +"From: ubuntu\n" +"\n" +"%post\n" +" apt-get -y update\n" +" apt-get -y install fortune cowsay lolcat\n" +"\n" +"%environment\n" +" export LC_ALL=C\n" +" export PATH=/usr/games:$PATH\n" +"\n" +"%runscript\n" +" fortune | cowsay | lolcat\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:462 +msgid "This 'recipe' uses a docker image as basis (here: ubuntu) installs a few apt packages, modifies a few environment" +msgstr "" + +#: reproducible_environments/06/containers.md:463 +msgid "variables, and specifies the runscript (which is executed using the `singularity run` command). Details on the" +msgstr "" + +#: reproducible_environments/06/containers.md:464 +msgid "singularity definition file format can be found in the official [documentation](https://www.sylabs.io/docs/)." +msgstr "" + +#: reproducible_environments/06/containers.md:466 +msgid "A container image can then be built (requiring root!) via" +msgstr "" + +#: reproducible_environments/06/containers.md:468 +# code block +msgid "```\n" +"sudo singularity build lolcow.simg lolcow.def\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:472 +msgid "This will pull the ubuntu image from dockerhub, run the steps of the recipe in the definition file and produce a single" +msgstr "" + +#: reproducible_environments/06/containers.md:473 +msgid "output image file (`lolcow.simg`). Finally the runscript is executed as" +msgstr "" + +#: reproducible_environments/06/containers.md:475 +# code block +msgid "```\n" +"singularity run lolcow.simg\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:479 +msgid "Ideally, you should see a nice ASCII cow and a few words of wisdom, as in" +msgstr "" + +#: reproducible_environments/06/containers.md:481 +# code block +msgid "```\n" +"___________________________________\n" +"/ You will be called upon to help a \\\n" +"\\ friend in trouble. /\n" +"-----------------------------------\n" +" \\ ^__^\n" +" \\ (oo)\\_______\n" +" (__)\\ )\\/\\\n" +" ||----w |\n" +" || ||\n" +"```" +msgstr "" + +#: reproducible_environments/06/containers.md:493 +msgid "Being HPC compatible, singularity containers are also supported by a wide range of workflow management tools. For" +msgstr "" + +#: reproducible_environments/06/containers.md:494 +msgid "example, both [snakemake](https://snakemake.readthedocs.io/en/stable/) and" +msgstr "" + +#: reproducible_environments/06/containers.md:495 +msgid "[nextflow](https://www.nextflow.io/docs/latest/singularity.html) support job-specific singularity containers. This makes" +msgstr "" + +#: reproducible_environments/06/containers.md:496 +msgid "singularity containers uniquely suited for parallelizing workflows on HPC systems using the widely used" +msgstr "" + +#: reproducible_environments/06/containers.md:497 +msgid "[slurm](https://slurm.schedmd.com/documentation.html) workload manager. Using singularity containers and" +msgstr "" + +#: reproducible_environments/06/containers.md:498 +msgid "snakemake/nextflow is therefore a way of scaling reproducibility to massive scale and - as an added benefit - bringing" +msgstr "" + +#: reproducible_environments/06/containers.md:499 +msgid "workflows from a desktop machine to an HPC system no longer requires writing custom job submission scripts." +msgstr "" + +#: reproducible_environments/06/containers.md:501 +# header +msgid "#### Long-term storage of container images" +msgstr "" + +#: reproducible_environments/06/containers.md:503 +msgid "It is important to note that a mere container recipe file is not reproducible in itself since the build process depends" +msgstr "" + +#: reproducible_environments/06/containers.md:504 +msgid "on various (online) sources. Thus the same recipe file might lead to different images if the underlying sources were" +msgstr "" + +#: reproducible_environments/06/containers.md:505 +msgid "updated." +msgstr "" + +#: reproducible_environments/06/containers.md:507 +msgid "To achieve true reproducibility, it is therefore important to store the actual container _images_. For singularity" +msgstr "" + +#: reproducible_environments/06/containers.md:508 +msgid "images, this is particularly easy since an image is simply a large file. These can vary in size from a few tens of" +msgstr "" + +#: reproducible_environments/06/containers.md:509 +msgid "megabytes (microcontainers) to several gigabyte and are therefore not suited for being stored in a git repository" +msgstr "" + +#: reproducible_environments/06/containers.md:510 +msgid "themselves. A free, citable, and long-term solution to storing container images is [zenodo.org](https://zenodo.org/)" +msgstr "" + +#: reproducible_environments/06/containers.md:511 +msgid "which allows up to 50 Gb per repository. Since zenodo is minting DOIs for all content uploaded, the images are" +msgstr "" + +#: reproducible_environments/06/containers.md:512 +msgid "immediately citable. In contrast to [dockerhub](https://hub.docker.com/) (which also only accepts docker images)" +msgstr "" + +#: reproducible_environments/06/containers.md:513 +msgid "zenodo.org is also clearly geared towards long-term storage and discoverability via a sophisticated metadata system and" +msgstr "" + +#: reproducible_environments/06/containers.md:514 +msgid "thus ideally suited for storing scientific containers associated with particular analyses since these tend to not change" +msgstr "" + +#: reproducible_environments/06/containers.md:515 +msgid "over time." +msgstr "" + +#: reproducible_environments/06/containers.md:517 +# header +msgid "#### Words of Warning" +msgstr "" + +#: reproducible_environments/06/containers.md:519 +msgid "Even though singularity and docker might look similar, they are conceptually very different. Besides the obvious fact" +msgstr "" + +#: reproducible_environments/06/containers.md:520 +msgid "that singularity does not require root access to run containers, it also handles the distinction between the host and" +msgstr "" + +#: reproducible_environments/06/containers.md:521 +msgid "container file system differently. For instance, by default singularity includes a few bind points in the container," +msgstr "" + +#: reproducible_environments/06/containers.md:522 +msgid "namely:" +msgstr "" + +#: reproducible_environments/06/containers.md:524 +# unordered list +msgid "- `$HOME`" +msgstr "" + +#: reproducible_environments/06/containers.md:525 +# unordered list +msgid "- `/sys:/sys`" +msgstr "" + +#: reproducible_environments/06/containers.md:526 +# unordered list +msgid "- `/proc:/proc`" +msgstr "" + +#: reproducible_environments/06/containers.md:527 +# unordered list +msgid "- `/tmp:/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:528 +# unordered list +msgid "- `/var/tmp:/var/tmp`" +msgstr "" + +#: reproducible_environments/06/containers.md:529 +# unordered list +msgid "- `/etc/resolv.conf:/etc/resolv.conf`" +msgstr "" + +#: reproducible_environments/06/containers.md:530 +# unordered list +msgid "- `/etc/passwd:/etc/passwd`" +msgstr "" + +#: reproducible_environments/06/containers.md:531 +# unordered list +msgid "- `$PWD`" +msgstr "" + +#: reproducible_environments/06/containers.md:533 +msgid "Note, `$PWD` comes in handy since it implies that all files in the working directory are visible within the container." +msgstr "" + +#: reproducible_environments/06/containers.md:534 +msgid "Binding `$HOME` by default, however, also implies that software using configuration files from `$HOME` might behave in" +msgstr "" + +#: reproducible_environments/06/containers.md:535 +msgid "an unexpected way since the image specific configuration files are overwritten with the current users settings in" +msgstr "" + +#: reproducible_environments/06/containers.md:536 +msgid "`$HOME`. While this behaviour is handy in HPC scenarios, it is potentially dangerous for reproducible research. To avoid" +msgstr "" + +#: reproducible_environments/06/containers.md:537 +msgid "potential issues, any software installed in a singularity container should be pointed to a global, user-independent" +msgstr "" + +#: reproducible_environments/06/containers.md:538 +msgid "configuration files." +msgstr "" + +#: reproducible_environments/07/checklist.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/07/checklist.md:3 +# header +msgid "## Checklist" +msgstr "" + +#: reproducible_environments/07/checklist.md:5 +# unordered list +msgid "- [ ] Choose the most appropriate method for your project for capturing your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:6 +# unordered list +msgid "- [ ] Capture your computational environment" +msgstr "" + +#: reproducible_environments/07/checklist.md:7 +# unordered list +msgid "- [ ] Share your captured computational environment along with your results/analysis" +msgstr "" + +#: reproducible_environments/08/resources.md:1 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:3 +# header +msgid "## What to learn next" +msgstr "" + +#: reproducible_environments/08/resources.md:5 +msgid "We recommend reading the chapter on testing, and then the chapter on continuous integration. Note that the chapter on version control is a prerequisite for the chapter on continuous integration. The open research chapter also contains further information on sharing research reproducibly." +msgstr "" + +#: reproducible_environments/08/resources.md:7 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:9 +# header +msgid "## Further reading" +msgstr "" + +#: reproducible_environments/08/resources.md:11 +msgid "The [Docker documentation](https://docs.docker.com/get-started/) contains a lot of information about containers in general." +msgstr "" + +#: reproducible_environments/08/resources.md:13 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:15 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: reproducible_environments/08/resources.md:17 +msgid "**Binder:** A web-based service which allows users to upload and share fully-functioning versions of their projects in an environment they define." +msgstr "" + +#: reproducible_environments/08/resources.md:19 +msgid "**Computational environment:** Features of a computer which can impact the behaviour of work done on it, such as its operating system, what software it has installed, and what versions of software packages are installed." +msgstr "" + +#: reproducible_environments/08/resources.md:21 +msgid "**Conda:** A commonly used package management system." +msgstr "" + +#: reproducible_environments/08/resources.md:23 +msgid "**Container:** Lightweight files that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:25 +msgid "**Dockerfile:** A file used for creating Docker images" +msgstr "" + +#: reproducible_environments/08/resources.md:27 +msgid "**Image:** Files used for generating containers." +msgstr "" + +#: reproducible_environments/08/resources.md:29 +msgid "**Package management system:** A tool for installing, managing, and uninstalling software packages including specific versions." +msgstr "" + +#: reproducible_environments/08/resources.md:31 +msgid "**Virtual machine:** A simulated computer that can encapsulate and entire computational environment including its operating system, customised settings, software and files." +msgstr "" + +#: reproducible_environments/08/resources.md:33 +msgid "**YAML:** A human readable/writable markup language which used by many projects for configuration files." +msgstr "" + +#: reproducible_environments/08/resources.md:35 +msgid "" +msgstr "" + +#: reproducible_environments/08/resources.md:37 +# header +msgid "## Bibliography" +msgstr "" + +#: reproducible_environments/08/resources.md:39 +# header +msgid "### Materials in the \"what is a computational environment\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:41 +# unordered list +msgid "- [semantic versioning](https://semver.org) **Creative Commons - CC BY 3.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:43 +# header +msgid "### Materials in the \"how this will help you/why this is useful\" section" +msgstr "" + +#: reproducible_environments/08/resources.md:45 +# unordered list +msgid "- [A. Brinckman, et al., Computing environments for reproducibility: Capturing the \"Whole Tale\", Future Generation Computer Systems (2018), https://doi.org/10.1016/j.future.2017.12.029](https://www.sciencedirect.com/science/article/pii/S0167739X17310695) **Attribution 4.0 International (CC BY 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:46 +#: reproducible_environments/08/resources.md:50 +# unordered list +msgid "- [Paper presenting singularity](https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0177459) **CC0 1.0 Universal (CC0 1.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:48 +# header +msgid "### Materials in the summary of ways to capture computational environments section" +msgstr "" + +#: reproducible_environments/08/resources.md:52 +# header +msgid "### Materials in the package management systems section" +msgstr "" + +#: reproducible_environments/08/resources.md:54 +# unordered list +msgid "- [Package Managers](https://opensource.com/article/18/7/evolution-package-managers) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:55 +# unordered list +msgid "- [Talk by Will Furnass on Conda](https://github.com/willfurnass/conda-rses-pres/blob/master/content.md) **Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: reproducible_environments/08/resources.md:57 +# header +msgid "### Materials in the YAML files section" +msgstr "" + +#: reproducible_environments/08/resources.md:59 +# unordered list +msgid "- [YAML tutorial](https://gettaurus.org/docs/YAMLTutorial/) **[Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0)**" +msgstr "" + +#: reproducible_environments/08/resources.md:61 +# header +msgid "### Materials in the Binder section" +msgstr "" + +#: reproducible_environments/08/resources.md:63 +# unordered list +msgid "- [Binder illustration](https://opendreamkit.org/2017/11/02/use-case-publishing-reproducible-notebooks/) **Permission to use granted by Juliette Taka, Logilab and the OpenDreamKit project.**" +msgstr "" + +#: reproducible_environments/08/resources.md:64 +# unordered list +msgid "- [mybinder docs intro](https://github.com/jupyterhub/binder/blob/master/doc/introduction.rst) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:65 +# unordered list +msgid "- [Original zero to Binder tutorial](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:66 +# unordered list +msgid "- [Sarah Gibson's zero to Binder](https://github.com/alan-turing-institute/the-turing-way/blob/master/workshops/boost-research-reproducibility-binder/workshop-presentations/zero-to-binder.md) **MIT**" +msgstr "" + +#: reproducible_environments/08/resources.md:67 +# unordered list +msgid "- [Zero to Binder](https://github.com/Build-a-binder/build-a-binder.github.io/blob/master/workshop/10-zero-to-binder.md) **[BSD 3-Clause](https://github.com/binder-examples/requirements/blob/master/LICENSE)**" +msgstr "" + +#: reproducible_environments/08/resources.md:69 +# header +msgid "### Materials in the virtual machines section" +msgstr "" + +#: reproducible_environments/08/resources.md:71 +# unordered list +msgid "- [Bryan Brown LITA blog](https://litablog.org/2014/12/virtual-machines-in-a-nutshell/) **[Copyright granted for educational use](http://www.ala.org/copyright)**" +msgstr "" + +#: reproducible_environments/08/resources.md:73 +# header +msgid "### Materials in the containers section" +msgstr "" + +#: reproducible_environments/08/resources.md:75 +# unordered list +msgid "- [What is docker?](https://opensource.com/resources/what-docker) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:76 +# unordered list +msgid "- [What are containers?](https://opensource.com/resources/what-are-linux-containers?intcmp=7016000000127cYAAQ) **CC BY-SA 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:77 +# unordered list +msgid "- [Docker carpentry](http://www.manicstreetpreacher.co.uk/docker-carpentry/aio/) **Creative Commons Attribution 4.0**" +msgstr "" + +#: reproducible_environments/08/resources.md:78 +# unordered list +msgid "- [Geohackweek tutorial](https://geohackweek.github.io/Introductory/docker-tutorial_temp/) **Creative Commons Attribution 3.0 Unported**" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:1 +# header +msgid "# Reproducible environments" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:6 +msgid "| --------------------------------------------------------------------------------------------- | ---------- | ---------------------------------------------------------------------------------------- |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:7 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary | Experience with downloading software via the command line is particularly useful |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:8 +msgid "| [Version control](/version_control/version_control) | Helpful | Experience using git and GitHub are helpful for the section on [Binder](#Binder_section) |" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:10 +msgid "A tutorial on working via the command line can be found" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:11 +msgid "[here](https://programminghistorian.org/en/lessons/intro-to-bash)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:13 +msgid "Recommended skill level: intermediate-advanced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:15 +# header +msgid "## Table of contents" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:17 +# unordered list +msgid "- [Summary](#Summary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:18 +# unordered list +msgid " - [What is a computational environment?](#What_is_a_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:19 +# unordered list +msgid "- [How this will help you/why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:20 +# unordered list +msgid "- [Summary of ways to capture computational environments](./01/options#Summary_of_ways_to_capture_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:21 +# unordered list +msgid " - [Package management systems outline](./01/options#Package_management_systems_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:22 +# unordered list +msgid " - [Binder outline](./01/options#Binder_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:23 +# unordered list +msgid " - [Virtual machines outline](./01/options#Virtual_machines_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:24 +# unordered list +msgid " - [Containers outline](./01/options#Containers_outline)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:25 +# unordered list +msgid "- [Package management systems](./02/package-management#Package_management_systems)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:26 +# unordered list +msgid " - [What does Conda do?](./02/package-management#What_does_Conda_do)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:27 +# unordered list +msgid " - [Installing Conda](./02/package-management#Installing_Conda)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:28 +# unordered list +msgid " - [Making and using environments](./02/package-management#Making_and_using_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:29 +# unordered list +msgid " - [Deactivating and deleting environments](./02/package-management#Deactivating_and_deleting_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:30 +# unordered list +msgid " - [Installing and removing packages within an environment](./02/package-management#Installing_and_removing_packages_within_an_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:31 +# unordered list +msgid " - [Exporting and reproducing computational environments](./02/package-management#Exporting_and_reproducing_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:32 +# unordered list +msgid "- [YAML files](./03/yaml#YAML_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:33 +# unordered list +msgid " - [YAML syntax](./03/yaml#YAML_syntax)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:34 +# unordered list +msgid " - [Scalars](./03/yaml#Scalars)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:35 +# unordered list +msgid " - [Lists and Dictionaries](./03/yaml#Lists_and_Dictionaries)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:36 +# unordered list +msgid " - [YAML gotchas](./03/yaml#YAML_gotchas)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:37 +# unordered list +msgid " - [How to use YAML to define computational environments](./03/yaml#How_to_use_YAML_to_define_computational_environments)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:38 +# unordered list +msgid " - [Security issues](./03/yaml#Security_issues)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:39 +# unordered list +msgid "- [Binder](./04/binder#Binder_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:40 +# unordered list +msgid " - [Disambiguation](./04/binder#Disambiguation)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:41 +# unordered list +msgid " - [Creating a Binder for a project](./04/binder#Creating_a_binder_for_a_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:42 +# unordered list +msgid " - [Step 1: Specify your computational environment](./04/binder#Step_1_Specify_your_computational_environment)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:43 +# unordered list +msgid " - [Step 2: Put your code on GitHub](./04/binder#Step_2_Put_your_code_on_GitHub)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:44 +# unordered list +msgid " - [Step 3: Generate a link to a Binder of your project](./04/binder#Step_3_Generate_a_link_to_a_Binder_of_your_project)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:45 +# unordered list +msgid " - [Including data in a Binder](./04/binder#Including_data_in_a_Binder)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:46 +# unordered list +msgid " - [Small public files](./04/binder#Small_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:47 +# unordered list +msgid " - [Medium public files](./04/binder#Medium_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:48 +# unordered list +msgid " - [Large public files](./04/binder#Large_public_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:49 +# unordered list +msgid "- [Virtual machines](./05/virtual-machines#Virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:50 +# unordered list +msgid " - [What are virtual machines?](./05/virtual-machines#What_are_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:51 +# unordered list +msgid " - [Using virtual machines for reproducible research](./05/virtual-machines#Using_virtual_machines_for_reproducible_research)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:52 +# unordered list +msgid " - [Setting up a virtual machine](./05/virtual-machines#Setting_up_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:53 +# unordered list +msgid " - [Starting a virtual machine](./05/virtual-machines#Starting_a_virtual_machine)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:54 +# unordered list +msgid " - [Sharing virtual virtual machines](./05/virtual-machines#Sharing_virtual_virtual_machines)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:55 +# unordered list +msgid "- [Containers](./06/containers#Containers_section)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:56 +# unordered list +msgid " - [What are containers?](./06/containers#What_are_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:57 +# unordered list +msgid " - [What are images](./06/containers#What_are_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:58 +# unordered list +msgid " - [What is Docker?](./06/containers#What_is_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:59 +# unordered list +msgid " - [Installing Docker](./06/containers#Installing_Docker)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:60 +# unordered list +msgid " - [Key commands](./06/containers#Key_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:61 +# unordered list +msgid " - [Writing Dockerfiles](./06/containers#Writing_Dockerfiles)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:62 +# unordered list +msgid " - [WORKDIR](./06/containers#WORKDIR)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:63 +# unordered list +msgid " - [Other commands](./06/containers#Other_commands)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:64 +# unordered list +msgid " - [Building images and .dockerignore files](./06/containers#Building_images_and_dockerignore_files)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:65 +# unordered list +msgid " - [Sharing images](./06/containers#Sharing_images)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:66 +# unordered list +msgid " - [Singularity](./06/containers#Singularity)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:67 +# unordered list +msgid " - [Copying files to and from containers](./06/containers#Copying_files_to_and_from_containers)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:68 +# unordered list +msgid " - [Volumes](./06/containers#Volumes)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:69 +# unordered list +msgid "- [Checklist](./07/checklist#Checklist)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:70 +# unordered list +msgid "- [What to learn next](./08/resources#What_to_learn_next)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:71 +# unordered list +msgid "- [Further reading](./08/resources#Further_reading)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:72 +# unordered list +msgid "- [Definitions/glossary](./08/resources#Definitions_glossary)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:73 +# unordered list +msgid "- [Bibliography](./08/resources#Bibliography)" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:75 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:77 +# header +msgid "## Summary" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:79 +msgid "Every computer has its own unique computational environment consisting of its operating system, what software it has" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:80 +msgid "installed, what versions of software packages are installed, and other features that we will describe later. If a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:81 +msgid "research project is carried out on one computer and then that project and all its associated files are transferred to a" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:82 +msgid "different computer, there is no guarantee the analysis will even be able to run, let alone generate the same results, if" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:83 +msgid "the analysis is dependent on any of the considerations listed above." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:85 +msgid "In order for research to be reproducible, the computational environment that it was conducted in must be captured in" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:86 +msgid "such a way that it can be replicated by others. This chapter describes a variety of methods for capturing computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:87 +msgid "environments and gives guidance on their strengths and weaknesses." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:89 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:91 +# header +msgid "### What is a computational environment?" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:93 +msgid "In broad terms, the computational environment is the system where a program is run. This includes features of hardware" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:94 +msgid "(such as the numbers of cores in any CPUs) and features of software (such as the operating system, programming languages," +msgstr "" + +#: reproducible_environments/reproducible_environments.md:95 +msgid "supporting packages and other pieces of software that are installed, and their versions and configuration)." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:97 +msgid "Software versions are often defined via [semantic versioning](https://semver.org). In this system three numbers, e.g" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:98 +msgid "2.12.4 are used to define each version of a piece of software. When a change is made to the software its version is" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:99 +msgid "incremented. These three numbers follow the pattern MAJOR.MINOR.PATCH, and are incremented as follows:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:101 +# unordered list +msgid "- MAJOR: significant changes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:102 +# unordered list +msgid "- MINOR: to add functionality" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:103 +# unordered list +msgid "- PATCH: for bug fixes" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:105 +msgid "" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:107 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:109 +msgid "Let's go though an example of why computational environments are important. Say I have a very simple Python script:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:111 +# code block +msgid "```\n" +"a = 1\n" +"b = 5\n" +"print(a/b)\n" +"```" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:117 +msgid "One divided by five is `0.2`, and this is what is printed if the script is run using Python 3. However, if a slightly" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:118 +msgid "older version of Python; Python 2 is used, the result printed is `0`. This is because integer division is applied to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:119 +msgid "integers in Python 2, but (normal) division is applied to all types, including integers, in Python 3." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:121 +msgid "Therefore this extremely simple script returns _different_ answers depending on the computational environment in which" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:122 +msgid "it is run. Using the wrong version of Python is easy to do, and demonstrates how a perfectly valid piece of code can" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:123 +msgid "give different results depending on its environment. If such issues can impact a simple script like this, imagine how" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:124 +msgid "many could appear in a complex analysis procedure which may involve thousands of lines of code and dozens of dependent" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:125 +msgid "packages." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:127 +msgid "It is vital for researchers to understand and capture the computational environments in which they are conducting their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:128 +msgid "work, as it has the potential to impact three parties:" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:130 +# unordered list +msgid "- The researcher themselves. The researcher's working environment evolves over time as they update software, install new" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:131 +msgid " software, and move to different computers. If the project environment is not captured and the researcher needs to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:132 +msgid " return to that project after months or years (as is common in research), they will be unable to confidently do so as" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:133 +msgid " they will have no way of knowing what changes to the environment have occurred and what impact those changes might" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:134 +msgid " have on their ability to run the code, and on the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:135 +# unordered list +msgid "- Collaborators. Much research is now collaborative, and conducting research in multiple different computational" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:136 +msgid " environments opens up a minefield of potential bugs. Trying to fix these kinds of issues is often time consuming and" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:137 +msgid " frustrating as researchers have to figure out what the differences between computational environments are, and their" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:138 +msgid " effects. Worse, some bugs may remain undetected, potentially impacting the results." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:139 +# unordered list +msgid "- Science itself. Scholarly research has evolved significantly over the past decade, but the same cannot be said for the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:140 +msgid " methods by which research processes are captured and disseminated. In fact, the primary method for dissemination - the" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:141 +msgid " scholarly publication - is largely unchanged since the advent of the scientific journal in the 1660s. This is no" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:142 +msgid " longer sufficient to verify, reproduce, and extend scientific results. Despite the increasing recognition of the need" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:143 +msgid " to share all aspects of the research process, scholarly publications today are often disconnected from the underlying" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:144 +msgid " analysis and, crucially, the computational environment that produced the findings. For research to be reproducible" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:145 +msgid " researchers must publish and distribute the entire contained analysis, not just its results. The analysis should be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:146 +msgid " _mobile_. Mobility of compute is defined as the ability to define, create, and maintain a workflow locally while" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:147 +msgid " remaining confident that the workflow can be executed elsewhere. In essence, mobility of compute means being able to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:148 +msgid " contain the entire software stack, from data files up through the library stack, and reliably move it from system to" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:149 +msgid " system. Any research that is limited to where it can be deployed is instantly limited in the extent that it can be" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:150 +msgid " reproduced." +msgstr "" + +#: reproducible_environments/reproducible_environments.md:152 +msgid "This chapter will describe how to capture, preserve and share computational environments along with code to ensure" +msgstr "" + +#: reproducible_environments/reproducible_environments.md:153 +msgid "research is reproducible." +msgstr "" + diff --git a/book/content/po/reviewing.es.po b/book/content/po/reviewing.es.po new file mode 100644 index 00000000000..da158694aff --- /dev/null +++ b/book/content/po/reviewing.es.po @@ -0,0 +1,551 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reviewing/01/how_helpful.md:1 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: reviewing/04/checklists_bib.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: reviewing/04/checklists_bib.md:37 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + +#: reviewing/04/checklists_bib.md:42 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:43 +# header +msgid "## Further reading" +msgstr "" + +#: reviewing/04/checklists_bib.md:45 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:53 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:54 +# header +msgid "## Bibliography" +msgstr "" + +#: reviewing/04/checklists_bib.md:56 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: reviewing/reviewing.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: reviewing/reviewing.md:7 +msgid "" +msgstr "" + +#: reviewing/reviewing.md:8 +# header +msgid "## Summary" +msgstr "" + +#: reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + diff --git a/book/content/po/reviewing.pot b/book/content/po/reviewing.pot new file mode 100644 index 00000000000..daf8420bc0a --- /dev/null +++ b/book/content/po/reviewing.pot @@ -0,0 +1,551 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reviewing/01/how_helpful.md:1 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: reviewing/04/checklists_bib.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: reviewing/04/checklists_bib.md:37 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + +#: reviewing/04/checklists_bib.md:42 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:43 +# header +msgid "## Further reading" +msgstr "" + +#: reviewing/04/checklists_bib.md:45 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:53 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:54 +# header +msgid "## Bibliography" +msgstr "" + +#: reviewing/04/checklists_bib.md:56 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: reviewing/reviewing.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: reviewing/reviewing.md:7 +msgid "" +msgstr "" + +#: reviewing/reviewing.md:8 +# header +msgid "## Summary" +msgstr "" + +#: reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + diff --git a/book/content/po/reviewing.tr.po b/book/content/po/reviewing.tr.po new file mode 100644 index 00000000000..daf8420bc0a --- /dev/null +++ b/book/content/po/reviewing.tr.po @@ -0,0 +1,551 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reviewing/01/how_helpful.md:1 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: reviewing/04/checklists_bib.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: reviewing/04/checklists_bib.md:37 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + +#: reviewing/04/checklists_bib.md:42 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:43 +# header +msgid "## Further reading" +msgstr "" + +#: reviewing/04/checklists_bib.md:45 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:53 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:54 +# header +msgid "## Bibliography" +msgstr "" + +#: reviewing/04/checklists_bib.md:56 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: reviewing/reviewing.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: reviewing/reviewing.md:7 +msgid "" +msgstr "" + +#: reviewing/reviewing.md:8 +# header +msgid "## Summary" +msgstr "" + +#: reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + diff --git a/book/content/po/reviewing.zh_CN.po b/book/content/po/reviewing.zh_CN.po new file mode 100644 index 00000000000..a5ccf83e060 --- /dev/null +++ b/book/content/po/reviewing.zh_CN.po @@ -0,0 +1,552 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: reviewing/01/how_helpful.md:1 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: reviewing/01/how_helpful.md:3 +msgid "As with [testing](#Testing), a key objective of code review is to remove mistakes and bad practice from changes made to a software project before those changes enter the master code base. However, it also has a number of other direct and indirect benefits to projects. These are discussed below." +msgstr "" + +#: reviewing/01/how_helpful.md:5 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:6 +# header +msgid "### Catching bugs and elementary errors" +msgstr "" + +#: reviewing/01/how_helpful.md:8 +msgid "A simple objective of the review process is to catch bugs and elementary errors in proposed changes before they make it into the trunk code. In this way, code review shares aspects with testing. However, a robust testing programme should reduce the importance of code review for identifying these kinds of straightforward errors, as the tests should catch them before the code makes it to review stage. So in principle, this function of code review should be restricted to trivial changes like documentation typos. In practice, however, code review does act as an important second line of defence against all kinds of bugs and errors." +msgstr "" + +#: reviewing/01/how_helpful.md:10 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:11 +# header +msgid "### Improvements to testing" +msgstr "" + +#: reviewing/01/how_helpful.md:13 +msgid "As noted above, review should, and often does, catch actual bugs in proposed code changes. This, of course, is a sign that the proposed changes were not well-tested enough in the first place. A major aim of code review is to highlight places in the code where existing or newly developed testing processes are inadequate. In this way, code review helps to ensure the future health of the code base by providing a second perspective on what kinds of tests are needed - not only now, but also under hypothetical scenarios that could arise in the future as the code evolves." +msgstr "" + +#: reviewing/01/how_helpful.md:15 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:16 +# header +msgid "### Documentation" +msgstr "" + +#: reviewing/01/how_helpful.md:18 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:19 +msgid "Thorough documentation is a key component of reproducibility and of sustainable software more generally. Code review provides another pair of eyes to consider whether the documentation provided along with the proposed code changes is fit-for-purpose. This is doubly valuable, as the reviewer looking in from outside the development process may have a clearer perspective than the coder on whether new documentation offers enough information for a user coming to the code for the first time." +msgstr "" + +#: reviewing/01/how_helpful.md:21 +msgid "This kind of feedback on documentation applies equally to user-facing documentation and to inline comments." +msgstr "" + +#: reviewing/01/how_helpful.md:23 +# header +msgid "### Readability" +msgstr "" + +#: reviewing/01/how_helpful.md:25 +msgid "Related to documentation, code review can also help to ensure that code is readable and easy to understand. Having a second pair of eyes can help spot areas where the code might be difficult to follow. The more readable your code is, the easier it will be for other developers to reproduce your code for their own purposes." +msgstr "" + +#: reviewing/01/how_helpful.md:28 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:29 +# header +msgid "### Style enforcement" +msgstr "" + +#: reviewing/01/how_helpful.md:31 +msgid "Many projects enforce certain code style guidelines, be they widely-adopted standards (for example, [PEP8](https://www.python.org/dev/peps/pep-0008/), the [Google C++ style guide](https://google.github.io/styleguide/cppguide.html)) or more project-specific conventions. Code review provides an opportunity to ensure all proposed changes meet the minimum require standards for the project." +msgstr "" + +#: reviewing/01/how_helpful.md:33 +msgid "" +msgstr "" + +#: reviewing/01/how_helpful.md:34 +# header +msgid "### Group knowledge and cohesion" +msgstr "" + +#: reviewing/01/how_helpful.md:36 +msgid "Code review practices provide significant advantages outwith simply defending the health of the trunk code of a project when changes are proposed. Peer-to-peer review creates two-way exchange of information across a web strung between all contributing members of a team. This provides effective, organic transfer of best practice." +msgstr "" + +#: reviewing/01/how_helpful.md:38 +msgid "Reviews conducted in the right spirit (see especially [here](#Be_nice)) also serve an important purpose in bringing team members together and creating group cohesion. In particular, good reviews by core team members of the work of newcomers to a project can help make those newcomers feel welcomed and valued, and encourage their continued participation." +msgstr "" + +#: reviewing/02/best_practice.md:1 +# header +msgid "## Best practice" +msgstr "" + +#: reviewing/02/best_practice.md:3 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:4 +# header +msgid "### Be nice!" +msgstr "" + +#: reviewing/02/best_practice.md:6 +msgid "As with all open-source and collaborative enterprises, good internet etiquette makes the whole process go more smoothly. Perhaps most importantly, always assume good faith on both sides of the review interaction, and always be constructive. These principles are true for the review process beyond almost any other project aspect, since it necessarily involves criticism, potentially between two complete strangers. If you're the coder, don't waste your reviewer's time. If you're the reviewer, listen to what the coder is telling you in reply, and work collaboratively with them to make the code better." +msgstr "" + +#: reviewing/02/best_practice.md:8 +# header +msgid "### Avoid being subjective" +msgstr "" + +#: reviewing/02/best_practice.md:9 +msgid "Code reviews should strive to be as objective as possible. Of course, subjective coding preferences may come up in any project. However, such preferences wherever possible should be decided at the project level beforehand. Thus, one can avoid the situation where an opinion might be passed of as fact. Instead suggestions can be supported by pointing to documented preferences that have been set up in advance. If you do come across undocumented preferences, discuss them with the team again and agree if you would like to add the preference to the checklist of your code review process. " +msgstr "" + +#: reviewing/02/best_practice.md:11 +# header +msgid "### Specify crucial versus optional changes" +msgstr "" + +#: reviewing/02/best_practice.md:12 +msgid "You might want to differentiate between changes that are crucial and changes that are nice to have. For example, comments that begin \"You might...\" could be used to express suggestions the reviewers want the coder to consider but are not essential. These can be particularly useful to guide inexperienced coders to write better code while not being too nitpicky. The coder can then decide to ignore these non-crucial comments if they don't agree. Reviewers could use comments that begin \"You must...\" to specify those that are not optional." +msgstr "" + +#: reviewing/02/best_practice.md:15 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:16 +# header +msgid "### Keep it collaborative" +msgstr "" + +#: reviewing/02/best_practice.md:17 +msgid "Unlike traditional, \"academic-style\" peer review, most code review systems have a number of advantages: they're rarely anonymous, they're public-facing, and without the middleman of an editor, contact between reviewer and review-ee can be direct and rapid. This means code review is typically a fast, flexible, and interactive process. Good peer review will be fully collaborative, where once a potential query has been flagged by a reviewer, the two involved parties can work forward together to find a solution. It's also not atypical for third parties to chime in during the discussion threads that can grow under more gnarly review comments, either voluntarily or by request. This is all to the good." +msgstr "" + +#: reviewing/02/best_practice.md:19 +# header +msgid "### Review code in small chunks and quickly" +msgstr "" + +#: reviewing/02/best_practice.md:20 +msgid "Reviewing code in small chunks incrementally as the project is developing can help make the code review process a lot more efficient. It is a lot more difficult to review an enormous codebase once significant mistakes have been introduced. If mistakes can be spotted early in the process, they are much easier to fix and this will help with the overall code development process." +msgstr "" + +#: reviewing/02/best_practice.md:22 +# header +msgid "### Be okay with taking the discussion offline" +msgstr "" + +#: reviewing/02/best_practice.md:23 +msgid "Sometimes, with more complex code reviews, online communication can lead to unproductive conversations. Setting up an in-person meeting can help to resolve some of the trickier issues in a more collaborative and friendly manner." +msgstr "" + +#: reviewing/02/best_practice.md:25 +msgid "" +msgstr "" + +#: reviewing/02/best_practice.md:26 +# header +msgid "### Who reviews?" +msgstr "" + +#: reviewing/02/best_practice.md:28 +msgid "Individual large-scale development projects will likely have existing, concrete rules for how reviewers are allocated to individual pull requests. These rules serve to balance the group workload and to maximise the various benefits of the process to the project and its participants. The very largest projects may even have dedicated staff - or teams of staff - to act as reviewers. In contrast, within small-scale projects where the developers all typically already know each other, typical practice is for the coder to tag someone in the group who they feel will have enough knowledge of this part of the code to do a good job in a reasonable amount of time. In practice, the point of transition between the structured and unstructured models will become very obvious within a growing project - typically when certain members of the core personnel start to complain about the uneven workload for reviewing they are under!" +msgstr "" + +#: reviewing/02/best_practice.md:30 +msgid "For projects where multiple rounds of review on similar material are likely and long development cycles are anticipated, a degree of strategic thinking on who completes reviews is sensible. A single reviewer is likely to be able to make comments on code they have reviewed before much more efficiently. However, letting reviewer-coder pairs like this ossify is generally a bad idea, as it can lead to the same kinds of groupthink that the review process is designed to avoid in the first place. Individual projects will tend to find this balance for themselves." +msgstr "" + +#: reviewing/02/best_practice.md:32 +msgid "Typically, code reviews can only be performed by an authorised subset of contributors within larger projects." +msgstr "" + +#: reviewing/03/typical_workflows.md:1 +# header +msgid "## Typical workflows (with particular reference to Github)" +msgstr "" + +#: reviewing/03/typical_workflows.md:3 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:4 +# header +msgid "### Formal vs informal reviews" +msgstr "" + +#: reviewing/03/typical_workflows.md:6 +msgid "This section focuses on the typical workflows behind a formal review process, as commonly implemented within a social coding environment like Github. However, it bears stating that **all review of code is very valuable**, including informal or ad-hoc approaches. Indeed, this kind of informal \"over the shoulder\" peer review can form a key preliminary component even in highly formalised review pipelines, saving a lot of stress and arguing once the formal stage begins." +msgstr "" + +#: reviewing/03/typical_workflows.md:8 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:9 +# header +msgid "### Forks and branches" +msgstr "" + +#: reviewing/03/typical_workflows.md:11 +msgid "For a formal review process to work effectively, it's imperative that the project is using good [version control](/version_control/version_control). The review step occurs between the points where the coder believes their contribution is complete and where that contribution is merged into the trunk code for the project, and so it is intimately associated with a single pull request. Creation of the review and discussion between the reviewer and the coder occurs once the pull request is made and before it is merged into the master. In the github system, the review is begun directly from and often accessed through the pull request page." +msgstr "" + +#: reviewing/03/typical_workflows.md:13 +msgid "Within the Github environment, projects can be configured to *require* a review before a given pull request can be merged. Even if this option hasn't been selected, it's still possible (and indeed best practice) to manually request a review on a pending PR." +msgstr "" + +#: reviewing/03/typical_workflows.md:15 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:16 +# header +msgid "### Prepare the code" +msgstr "" + +#: reviewing/03/typical_workflows.md:18 +msgid "Before requesting a review, be sure you've met all the obvious quality benchmarks for the project you are contributing to. This means making sure:" +msgstr "" + +#: reviewing/03/typical_workflows.md:20 +# unordered list +msgid "- you have created [documentation](#Documentation) to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:21 +# unordered list +msgid "- you have [tested](#Improvements_to_testing) your code to the required standards of the project," +msgstr "" + +#: reviewing/03/typical_workflows.md:22 +# unordered list +msgid "- your code is not causing the tests in the main project to fail (many [continuous integration](/continuous_integration/continuous_integration) systems will test this automatically for you once you create the PR), and" +msgstr "" + +#: reviewing/03/typical_workflows.md:23 +# unordered list +msgid "- you believe your code meets the declared [style guide](#Style_enforcement) for the project." +msgstr "" + +#: reviewing/03/typical_workflows.md:25 +msgid "A reviewer should check these things, but defects on these fronts should be by occasional oversight, rather than systematic." +msgstr "" + +#: reviewing/03/typical_workflows.md:27 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:28 +# header +msgid "### Create and discuss the review; make the changes" +msgstr "" + +#: reviewing/03/typical_workflows.md:30 +msgid "At this point, the review process can begin. In Github, the reviewer can provide both general comments as well as line-by-line comments. Each comment becomes its own comment thread, permitting back-and-forth discussion about each issue as required. This interaction should allow consensus to be reached on every comment. In most cases, the reviewer has final say if a consensus cannot be found." +msgstr "" + +#: reviewing/03/typical_workflows.md:32 +msgid "Once post-review changes have been made to the code, make final updates the comments as needed to complete a papertrail of what has been done and the reasoning behind it." +msgstr "" + +#: reviewing/03/typical_workflows.md:34 +msgid "" +msgstr "" + +#: reviewing/03/typical_workflows.md:35 +# header +msgid "### Make the merge" +msgstr "" + +#: reviewing/03/typical_workflows.md:37 +msgid "Once the review process is complete, the merge can occur. Individual projects typically have rules and/or guidelines for whether the coder or the reviewer actually presses the merge button, so check. In many cases, project workflows make completion of a review and its sign-off by the reviewer a formal precondition of performing the merge. For the avoidance of doubt, adopting this principle even for small or informal projects is probably sensible." +msgstr "" + +#: reviewing/04/checklists_bib.md:1 +# header +msgid "## Checklists" +msgstr "" + +#: reviewing/04/checklists_bib.md:3 +msgid "The following presents some possible checklists for both the coder and the reviewer, as part of a formal review process." +msgstr "" + +#: reviewing/04/checklists_bib.md:5 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:6 +# header +msgid "### For the coder" +msgstr "" + +#: reviewing/04/checklists_bib.md:8 +# unordered list +msgid "- [ ] Does the new code meet project standards? In particular," +msgstr "" + +#: reviewing/04/checklists_bib.md:9 +# unordered list +msgid " - [ ] Is there documentation?" +msgstr "" + +#: reviewing/04/checklists_bib.md:10 +# unordered list +msgid " - [ ] Are there new tests for the new material?" +msgstr "" + +#: reviewing/04/checklists_bib.md:11 +# unordered list +msgid " - [ ] Do these tests pass locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:12 +# unordered list +msgid " - [ ] Are you following any declared style guides?" +msgstr "" + +#: reviewing/04/checklists_bib.md:13 +# unordered list +msgid " - [ ] Are the tests in the rest of the code base still passing locally?" +msgstr "" + +#: reviewing/04/checklists_bib.md:14 +# unordered list +msgid "- [ ] Create the pull request; wait for any CI checks to complete." +msgstr "" + +#: reviewing/04/checklists_bib.md:15 +# unordered list +msgid "- [ ] Consult the CI reports. Did all the builds and tests complete?" +msgstr "" + +#: reviewing/04/checklists_bib.md:16 +# unordered list +msgid "- [ ] If necessary, now formally request a review." +msgstr "" + +#: reviewing/04/checklists_bib.md:17 +# unordered list +msgid "- [ ] Once review is complete, discuss any comments necessary." +msgstr "" + +#: reviewing/04/checklists_bib.md:18 +# unordered list +msgid "- [ ] Make the changes, and record the changes made against appropriate comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:19 +# unordered list +msgid "- [ ] Check that the reviewer knows you believe you have fully addressed the review." +msgstr "" + +#: reviewing/04/checklists_bib.md:21 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:22 +# header +msgid "### For the reviewer" +msgstr "" + +#: reviewing/04/checklists_bib.md:24 +# unordered list +msgid "- [ ] Check the code meets basic project style, if this is not automatically checked by CI." +msgstr "" + +#: reviewing/04/checklists_bib.md:25 +# unordered list +msgid "- [ ] Check there are tests & documentation to necessary standards." +msgstr "" + +#: reviewing/04/checklists_bib.md:26 +# unordered list +msgid "- [ ] Read the code, carefully." +msgstr "" + +#: reviewing/04/checklists_bib.md:27 +# unordered list +msgid " - [ ] Is all the code easily understood? " +msgstr "" + +#: reviewing/04/checklists_bib.md:28 +# unordered list +msgid " - [ ] Is it clear what all sections of the code do?" +msgstr "" + +#: reviewing/04/checklists_bib.md:29 +# unordered list +msgid " - [ ] Are the logic and approach in the proposed changes clear?" +msgstr "" + +#: reviewing/04/checklists_bib.md:30 +# unordered list +msgid " - [ ] Are the logic and the approach both sound?" +msgstr "" + +#: reviewing/04/checklists_bib.md:31 +# unordered list +msgid " - [ ] Do the tests actually ensure the code is robust in its intended use?" +msgstr "" + +#: reviewing/04/checklists_bib.md:32 +# unordered list +msgid " - [ ] Are there any bugs or other defects?" +msgstr "" + +#: reviewing/04/checklists_bib.md:33 +# unordered list +msgid "- [ ] As needed, engage constructively with the coder if they disagree on certain points in order to come to a consensus." +msgstr "" + +#: reviewing/04/checklists_bib.md:34 +# unordered list +msgid "- [ ] Once the coder believes changes are complete, check that they do indeed address all of the initial comments." +msgstr "" + +#: reviewing/04/checklists_bib.md:35 +# unordered list +msgid "- [ ] Approve the changes, and if it is your responsibility, make the merge." +msgstr "" + +#: reviewing/04/checklists_bib.md:37 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:38 +# header +msgid "## What to learn next" +msgstr "" + +#: reviewing/04/checklists_bib.md:40 +msgid "The thorough checking of tests, coverage, and code style by hand can be tedious, so this might be a good time to learn more about [continuous integration (CI)](/continuous_integration/continuous_integration)." +msgstr "" + +#: reviewing/04/checklists_bib.md:42 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:43 +# header +msgid "## Further reading" +msgstr "" + +#: reviewing/04/checklists_bib.md:45 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:46 +# header +msgid "## Definitions/glossary" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:51 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:53 +msgid "" +msgstr "" + +#: reviewing/04/checklists_bib.md:54 +# header +msgid "## Bibliography" +msgstr "" + +#: reviewing/04/checklists_bib.md:56 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + + + +#: reviewing/04/checklists_bib.md:62 +# header +msgid "### Materials used: General guidance and good practice for reviewing" +msgstr "" + + + +#: reviewing/reviewing.md:1 +# header +msgid "# Reviewing" +msgstr "" + +#: reviewing/reviewing.md:3 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: reviewing/reviewing.md:4 +msgid "| -------------|------------|-------|" +msgstr "" + +#: reviewing/reviewing.md:5 +msgid "| [Version control](/version_control/version_control) | Necessary | Understanding the way that [Github](https://github.com) arranges its branches, forks, and pull requests within repositories is needed. |" +msgstr "" + +#: reviewing/reviewing.md:7 +msgid "" +msgstr "" + +#: reviewing/reviewing.md:8 +# header +msgid "## Summary" +msgstr "" + +#: reviewing/reviewing.md:10 +msgid "Code review provides an additional way of testing code quality. Instead of relying simply on [tests](/testing/testing) which the original author puts together themselves, code review gets another programmer to look over the new code and assess it. The goal is to point out strengths and also potential areas of improvement." +msgstr "" + +#: reviewing/reviewing.md:12 +msgid "Code review is often done in pairs, with each reviewer also having some of their code reviewed by their partner. Doing this can help programmers to see and discuss issues and alternative approaches to tasks, and to learn new tips and tricks. This also means code review practices are particularly well-suited to projects with more than one contributor making changes, where each is working on different parts of the code. Nonetheless, even the smallest scale projects can harness these approaches with some creative project management." +msgstr "" + +#: reviewing/reviewing.md:14 +msgid "Because of their nature code reviews act a qualitative rather than quantitive tests, but are no less valuable for that." +msgstr "" + +#: reviewing/reviewing.md:16 +msgid "This section will provide an overview of rationales, best practice, and some possible workflows for code review. Some details refer specifically to github's code review functionality as a powerful and widely-used example of a formal code review system; however, equivalent and very similar systems are available elsewhere (for example, [Gitlab](https://about.gitlab.com)), and even informal code review practices can also be very beneficial to a project." +msgstr "" + diff --git a/book/content/po/risk_assessment.es.po b/book/content/po/risk_assessment.es.po new file mode 100644 index 00000000000..791c0a8f95e --- /dev/null +++ b/book/content/po/risk_assessment.es.po @@ -0,0 +1,248 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: risk_assessment/01/longreadriskassessment.md:1 +#: risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:2 +#: risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:4 +#: risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:5 +#: risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:9 +#: risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:11 +#: risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:13 +#: risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:15 +#: risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:17 +#: risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: risk_assessment/02/finalsummary.md:4 +# header +msgid "## Checklist" +msgstr "" + +#: risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: risk_assessment/02/finalsummary.md:7 +# header +msgid "## What to learn next" +msgstr "" + +#: risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: risk_assessment/02/finalsummary.md:10 +# header +msgid "## Further reading" +msgstr "" + +#: risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: risk_assessment/02/finalsummary.md:14 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: risk_assessment/02/finalsummary.md:17 +# header +msgid "## Bibliography" +msgstr "" + +#: risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: risk_assessment/risk_assessment.md:4 +#: risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: risk_assessment/risk_assessment.md:25 +#: risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: risk_assessment/risk_assessment.md:27 +# header +msgid "## Summary" +msgstr "" + +#: risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + diff --git a/book/content/po/risk_assessment.pot b/book/content/po/risk_assessment.pot new file mode 100644 index 00000000000..ba89f179035 --- /dev/null +++ b/book/content/po/risk_assessment.pot @@ -0,0 +1,248 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: risk_assessment/01/longreadriskassessment.md:1 +#: risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:2 +#: risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:4 +#: risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:5 +#: risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:9 +#: risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:11 +#: risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:13 +#: risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:15 +#: risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:17 +#: risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: risk_assessment/02/finalsummary.md:4 +# header +msgid "## Checklist" +msgstr "" + +#: risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: risk_assessment/02/finalsummary.md:7 +# header +msgid "## What to learn next" +msgstr "" + +#: risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: risk_assessment/02/finalsummary.md:10 +# header +msgid "## Further reading" +msgstr "" + +#: risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: risk_assessment/02/finalsummary.md:14 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: risk_assessment/02/finalsummary.md:17 +# header +msgid "## Bibliography" +msgstr "" + +#: risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: risk_assessment/risk_assessment.md:4 +#: risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: risk_assessment/risk_assessment.md:25 +#: risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: risk_assessment/risk_assessment.md:27 +# header +msgid "## Summary" +msgstr "" + +#: risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + diff --git a/book/content/po/risk_assessment.tr.po b/book/content/po/risk_assessment.tr.po new file mode 100644 index 00000000000..ba89f179035 --- /dev/null +++ b/book/content/po/risk_assessment.tr.po @@ -0,0 +1,248 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: risk_assessment/01/longreadriskassessment.md:1 +#: risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:2 +#: risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:4 +#: risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:5 +#: risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:9 +#: risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:11 +#: risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:13 +#: risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:15 +#: risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:17 +#: risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: risk_assessment/02/finalsummary.md:4 +# header +msgid "## Checklist" +msgstr "" + +#: risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: risk_assessment/02/finalsummary.md:7 +# header +msgid "## What to learn next" +msgstr "" + +#: risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: risk_assessment/02/finalsummary.md:10 +# header +msgid "## Further reading" +msgstr "" + +#: risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: risk_assessment/02/finalsummary.md:14 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: risk_assessment/02/finalsummary.md:17 +# header +msgid "## Bibliography" +msgstr "" + +#: risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: risk_assessment/risk_assessment.md:4 +#: risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: risk_assessment/risk_assessment.md:25 +#: risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: risk_assessment/risk_assessment.md:27 +# header +msgid "## Summary" +msgstr "" + +#: risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + diff --git a/book/content/po/risk_assessment.zh_CN.po b/book/content/po/risk_assessment.zh_CN.po new file mode 100644 index 00000000000..c78d9a5e220 --- /dev/null +++ b/book/content/po/risk_assessment.zh_CN.po @@ -0,0 +1,249 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: risk_assessment/01/longreadriskassessment.md:1 +#: risk_assessment/risk_assessment.md:6 +# header +msgid "## Longer read…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:2 +#: risk_assessment/risk_assessment.md:7 +msgid "We all use risk assessments all the time. Sometimes they’re formal procedures to ensure an activity is safe, but most of the time they’re the thought of a moment- Is this coffee too hot? Is there a bus coming? Software is no different, and using a risk assessment approach like the one described below can really help make your work successful and sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:4 +#: risk_assessment/risk_assessment.md:9 +# header +msgid "### The risk matrix" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:5 +#: risk_assessment/risk_assessment.md:10 +msgid "A risk matrix is a very popular way of quantifying what’s going on with the thing you’re interested in. One axis measures exposure in some way, and the other the impact of a mishap. The further from the origin, the more safeguards are needed to make the risk acceptable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:7 +msgid "![Impact vs complexity risk matrix](../../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:9 +#: risk_assessment/risk_assessment.md:14 +msgid "In our case, we will use ‘complexity’ and ‘impact’ as the two axes. Some case studies illustrate how it works…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:11 +#: risk_assessment/risk_assessment.md:16 +msgid "Case 1" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:13 +#: risk_assessment/risk_assessment.md:18 +# blockquote, which can be cascaded +msgid "> Richard needs to submit a 100 small jobs to the department cluster, with the names of the jobs varying according to a simple pattern. This is tedious and he wants to go outside and play. Therefore, Richard decides to write a short shell script to submit all the jobs. He pauses for a few seconds and asks:" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:15 +#: risk_assessment/risk_assessment.md:20 +# blockquote, which can be cascaded +msgid "> How complicated is this? It’ll only be about 1 screen of text." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:17 +#: risk_assessment/risk_assessment.md:22 +# blockquote, which can be cascaded +msgid "> What’s if it goes wrong? The jobs won’t submit or run and I’ll get some failure emails." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:19 +# blockquote, which can be cascaded +msgid "> Here, Richard decides that both the complexity and impact of this tiny piece of software are low. Therefore, using version control and writing documentation is disproportionate right now. He decides to do a dry run by echoing the submit line to the terminal so he can give it a quick check." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:21 +msgid ">A few weeks later, someone else in the lab wants to do the same thing. Richard offers his script as it worked quite well for him. The goalposts have moved. Richard pauses for a few more seconds to and reassesses the risk…" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:23 +msgid ">…5 years later, Richard’s script has evolved into a large workflow control system allowing several universities to manage complex workflows consisting of 1000’s of jobs being submitted to a range of different compute resources. The software now has a formal project board that sets the governance and direction of the software, ensuring that it is sustainable and meets the needs of the 100s of users worldwide." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:25 +msgid "Case 2..." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:27 +# blockquote, which can be cascaded +msgid "> Jemma has a problem with visualising some data. The usual library can’t cope with the format her data. She’s heard about Seth’s Friday afternoon project where he’s written a wrapper around this library to solve what seems to be the same problem. They have a coffee and decide to work together. During this coffee, they make some decisions about how they’re going to work successfully together- this is their risk assessment. Seth agrees to go away and improve the inline documentation and add some use case examples before sharing. Jemma agrees to set up a repository into which Seth will put the code." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:29 +# blockquote, which can be cascaded +msgid "> Over time, more people start to make use of this software, with feature requests adding complexity and changes in the underlying library causing breakages. Jemma and Seth agree that things are getting a bit risky because the impact of wrong results might cause problems with publishing results. They therefore introduce continuous integration tests and a review process to ensure things remain sustainable." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:31 +msgid "The key point of these case studies is that every piece of software has different needs to be sustainable, and these requirements can change over time. The use of version control, testing, documentation and other sustainability concepts are useful for managing risk. Using none of these tools leaves your software exposed to things going wrong, but using all of them from the outset can get in the way of innovation." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:32 +msgid "The risk assessment approach helps you find the right balance for now. Revisit the topic once in a while, or when something circumstances change." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:34 +# header +msgid "### More about measuring complexity" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:35 +msgid "One measure of complexity is line count. The more lines you have the more places there are to make a mistake. However, there are other things one might care about. How many libraries do you depend on? How many functions are there? All of these measure the complexity of the codebase." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:36 +msgid "Complexity can take other forms too. How many use cases are there? Does your blob counting software only get used for counting blobs in the biosciences? Are there people using it to count blobs in CCTV images? What types of computer are people using it on? CPU? GPU? Raspberry Pi?" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:37 +msgid "Take a broad view of your software." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:39 +# header +msgid "### More about measuring impact" +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:40 +msgid "What happens when (not if) your software doesn’t work? Sometimes, it just annoys you for a few minutes. However, other software going wrong can have huge consequences- the retraction of your seminal paper or even lives being lost." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:41 +msgid "Measuring the impact requires good knowledge of what your software is being used for. It can sometimes be difficult to keep track of this until things go wrong. However, one can try to head this off at the pass by asking questions like ‘is this piece of software I use for the analysis in my paper any good?’." +msgstr "" + +#: risk_assessment/01/longreadriskassessment.md:42 +msgid "Again, take a broad view of your software." +msgstr "" + +#: risk_assessment/02/finalsummary.md:1 +# header +msgid "## In summary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:2 +msgid "Understand your software and what it is used for. Knowing this helps you decide what sustainability concepts are appropriate for your needs. There are many tools and ecosystems that are commonly used to help you practice these concepts- github, Docker and many more. Read on to learn about these concepts and tools…" +msgstr "" + +#: risk_assessment/02/finalsummary.md:4 +# header +msgid "## Checklist" +msgstr "" + +#: risk_assessment/02/finalsummary.md:5 +# blockquote, which can be cascaded +msgid "> this can be done at the end or maybe as a separate checklist exercise, but please do note things down here as you go" +msgstr "" + +#: risk_assessment/02/finalsummary.md:7 +# header +msgid "## What to learn next" +msgstr "" + +#: risk_assessment/02/finalsummary.md:8 +# blockquote, which can be cascaded +msgid "> recommended next chapters that are a good next step up" +msgstr "" + +#: risk_assessment/02/finalsummary.md:10 +# header +msgid "## Further reading" +msgstr "" + +#: risk_assessment/02/finalsummary.md:11 +# blockquote, which can be cascaded +msgid "> top 3/5 resources to read on this topic (if they weren't licensed so we could include them above already) at the top, maybe in their own box/in bold." +msgstr "" + +#: risk_assessment/02/finalsummary.md:12 +# blockquote, which can be cascaded +msgid "> less relevant/favourite resources in case someone wants to dig into this in detail" +msgstr "" + +#: risk_assessment/02/finalsummary.md:14 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: risk_assessment/02/finalsummary.md:15 +# blockquote, which can be cascaded +msgid "> Link to the glossary here or copy in key concepts/definitions that readers should be aware of to get the most out of this chapter" +msgstr "" + +#: risk_assessment/02/finalsummary.md:17 +# header +msgid "## Bibliography" +msgstr "" + +#: risk_assessment/02/finalsummary.md:18 +# blockquote, which can be cascaded +msgid "> Credit/urls for any materials that form part of the chapter's text." +msgstr "" + +#: risk_assessment/risk_assessment.md:1 +# header +msgid "# Risk Assessment - deciding how to manage your software" +msgstr "" + +#: risk_assessment/risk_assessment.md:3 +# header +msgid "## TL;DR" +msgstr "" + +#: risk_assessment/risk_assessment.md:4 +#: risk_assessment/risk_assessment.md:28 +msgid "Use a risk assessment to help choose the appropriate sustainable software concepts for your project. Too little and your software is unsustainable; too much and you won’t be able to Get On With It. It can take just a few seconds, but gets you off on the right foot." +msgstr "" + +#: risk_assessment/risk_assessment.md:12 +msgid "![Impact vs complexity risk matrix](../figures/risk_matrix.png)" +msgstr "" + +#: risk_assessment/risk_assessment.md:23 +msgid "=======" +msgstr "" + +#: risk_assessment/risk_assessment.md:24 +# header +msgid "## Prerequisites/recommended skill level" +msgstr "" + +#: risk_assessment/risk_assessment.md:25 +#: risk_assessment/risk_assessment.md:31 +# blockquote, which can be cascaded +msgid "> This needs writing" +msgstr "" + +#: risk_assessment/risk_assessment.md:27 +# header +msgid "## Summary" +msgstr "" + +#: risk_assessment/risk_assessment.md:30 +# header +msgid "## How this will help you/why this is useful" +msgstr "" + diff --git a/book/content/po/testing.es.po b/book/content/po/testing.es.po new file mode 100644 index 00000000000..29ae192f932 --- /dev/null +++ b/book/content/po/testing.es.po @@ -0,0 +1,2006 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: testing/testing.md:52 +msgid "" +msgstr "" + +#: testing/testing.md:53 +# header +msgid "## Summary" +msgstr "" + +#: testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: testing/testing.md:57 +msgid "" +msgstr "" + +#: testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: testing/testing.md:76 +msgid "" +msgstr "" + +#: testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: testing/testing.md:85 +msgid "" +msgstr "" + +#: testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: testing/testing.md:90 +msgid "" +msgstr "" + +#: testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: testing/testing.md:97 +msgid "" +msgstr "" + +#: testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: testing/testing.md:106 +msgid "" +msgstr "" + +#: testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: testing/testing.md:111 +msgid "" +msgstr "" + +#: testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: testing/testing.md:122 +msgid "" +msgstr "" + +#: testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: testing/testing.md:127 +msgid "" +msgstr "" + +#: testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: testing/testing.md:139 +#: testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: testing/testing.md:154 +msgid "" +msgstr "" + +#: testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: testing/testing.md:165 +msgid "" +msgstr "" + +#: testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: testing/testing.md:179 +msgid "" +msgstr "" + +#: testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: testing/testing.md:184 +msgid "" +msgstr "" + +#: testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: testing/testing.md:239 +msgid "" +msgstr "" + +#: testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: testing/testing.md:246 +msgid "" +msgstr "" + +#: testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: testing/testing.md:267 +msgid "" +msgstr "" + +#: testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: testing/testing.md:270 +msgid "" +msgstr "" + +#: testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: testing/testing.md:297 +msgid "" +msgstr "" + +#: testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: testing/testing.md:325 +msgid "" +msgstr "" + +#: testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: testing/testing.md:334 +msgid "" +msgstr "" + +#: testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: testing/testing.md:353 +msgid "" +msgstr "" + +#: testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: testing/testing.md:360 +msgid "" +msgstr "" + +#: testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: testing/testing.md:369 +msgid "" +msgstr "" + +#: testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: testing/testing.md:395 +msgid "" +msgstr "" + +#: testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: testing/testing.md:467 +msgid "" +msgstr "" + +#: testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: testing/testing.md:480 +msgid "" +msgstr "" + +#: testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: testing/testing.md:516 +msgid "" +msgstr "" + +#: testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: testing/testing.md:523 +msgid "" +msgstr "" + +#: testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: testing/testing.md:537 +msgid "" +msgstr "" + +#: testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: testing/testing.md:550 +msgid "" +msgstr "" + +#: testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: testing/testing.md:557 +msgid "" +msgstr "" + +#: testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: testing/testing.md:574 +msgid "" +msgstr "" + +#: testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: testing/testing.md:579 +msgid "" +msgstr "" + +#: testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: testing/testing.md:618 +msgid "" +msgstr "" + +#: testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: testing/testing.md:627 +msgid "" +msgstr "" + +#: testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: testing/testing.md:632 +msgid "" +msgstr "" + +#: testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: testing/testing.md:643 +msgid "" +msgstr "" + +#: testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: testing/testing.md:655 +msgid "" +msgstr "" + +#: testing/testing.md:656 +# header +msgid "## What to learn next" +msgstr "" + +#: testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: testing/testing.md:660 +msgid "" +msgstr "" + +#: testing/testing.md:661 +# header +msgid "## Further reading" +msgstr "" + +#: testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: testing/testing.md:665 +msgid "" +msgstr "" + +#: testing/testing.md:666 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: testing/testing.md:700 +msgid "" +msgstr "" + +#: testing/testing.md:701 +# header +msgid "## Bibliography" +msgstr "" + +#: testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:705 +#: testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: testing/testing.md:726 +#: testing/testing.md:731 +#: testing/testing.md:737 +#: testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + diff --git a/book/content/po/testing.pot b/book/content/po/testing.pot new file mode 100644 index 00000000000..4aef804f4bb --- /dev/null +++ b/book/content/po/testing.pot @@ -0,0 +1,2006 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: testing/testing.md:52 +msgid "" +msgstr "" + +#: testing/testing.md:53 +# header +msgid "## Summary" +msgstr "" + +#: testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: testing/testing.md:57 +msgid "" +msgstr "" + +#: testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: testing/testing.md:76 +msgid "" +msgstr "" + +#: testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: testing/testing.md:85 +msgid "" +msgstr "" + +#: testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: testing/testing.md:90 +msgid "" +msgstr "" + +#: testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: testing/testing.md:97 +msgid "" +msgstr "" + +#: testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: testing/testing.md:106 +msgid "" +msgstr "" + +#: testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: testing/testing.md:111 +msgid "" +msgstr "" + +#: testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: testing/testing.md:122 +msgid "" +msgstr "" + +#: testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: testing/testing.md:127 +msgid "" +msgstr "" + +#: testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: testing/testing.md:139 +#: testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: testing/testing.md:154 +msgid "" +msgstr "" + +#: testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: testing/testing.md:165 +msgid "" +msgstr "" + +#: testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: testing/testing.md:179 +msgid "" +msgstr "" + +#: testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: testing/testing.md:184 +msgid "" +msgstr "" + +#: testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: testing/testing.md:239 +msgid "" +msgstr "" + +#: testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: testing/testing.md:246 +msgid "" +msgstr "" + +#: testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: testing/testing.md:267 +msgid "" +msgstr "" + +#: testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: testing/testing.md:270 +msgid "" +msgstr "" + +#: testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: testing/testing.md:297 +msgid "" +msgstr "" + +#: testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: testing/testing.md:325 +msgid "" +msgstr "" + +#: testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: testing/testing.md:334 +msgid "" +msgstr "" + +#: testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: testing/testing.md:353 +msgid "" +msgstr "" + +#: testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: testing/testing.md:360 +msgid "" +msgstr "" + +#: testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: testing/testing.md:369 +msgid "" +msgstr "" + +#: testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: testing/testing.md:395 +msgid "" +msgstr "" + +#: testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: testing/testing.md:467 +msgid "" +msgstr "" + +#: testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: testing/testing.md:480 +msgid "" +msgstr "" + +#: testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: testing/testing.md:516 +msgid "" +msgstr "" + +#: testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: testing/testing.md:523 +msgid "" +msgstr "" + +#: testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: testing/testing.md:537 +msgid "" +msgstr "" + +#: testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: testing/testing.md:550 +msgid "" +msgstr "" + +#: testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: testing/testing.md:557 +msgid "" +msgstr "" + +#: testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: testing/testing.md:574 +msgid "" +msgstr "" + +#: testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: testing/testing.md:579 +msgid "" +msgstr "" + +#: testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: testing/testing.md:618 +msgid "" +msgstr "" + +#: testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: testing/testing.md:627 +msgid "" +msgstr "" + +#: testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: testing/testing.md:632 +msgid "" +msgstr "" + +#: testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: testing/testing.md:643 +msgid "" +msgstr "" + +#: testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: testing/testing.md:655 +msgid "" +msgstr "" + +#: testing/testing.md:656 +# header +msgid "## What to learn next" +msgstr "" + +#: testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: testing/testing.md:660 +msgid "" +msgstr "" + +#: testing/testing.md:661 +# header +msgid "## Further reading" +msgstr "" + +#: testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: testing/testing.md:665 +msgid "" +msgstr "" + +#: testing/testing.md:666 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: testing/testing.md:700 +msgid "" +msgstr "" + +#: testing/testing.md:701 +# header +msgid "## Bibliography" +msgstr "" + +#: testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:705 +#: testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: testing/testing.md:726 +#: testing/testing.md:731 +#: testing/testing.md:737 +#: testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + diff --git a/book/content/po/testing.tr.po b/book/content/po/testing.tr.po new file mode 100644 index 00000000000..4aef804f4bb --- /dev/null +++ b/book/content/po/testing.tr.po @@ -0,0 +1,2006 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: testing/testing.md:52 +msgid "" +msgstr "" + +#: testing/testing.md:53 +# header +msgid "## Summary" +msgstr "" + +#: testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: testing/testing.md:57 +msgid "" +msgstr "" + +#: testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: testing/testing.md:76 +msgid "" +msgstr "" + +#: testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: testing/testing.md:85 +msgid "" +msgstr "" + +#: testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: testing/testing.md:90 +msgid "" +msgstr "" + +#: testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: testing/testing.md:97 +msgid "" +msgstr "" + +#: testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: testing/testing.md:106 +msgid "" +msgstr "" + +#: testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: testing/testing.md:111 +msgid "" +msgstr "" + +#: testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: testing/testing.md:122 +msgid "" +msgstr "" + +#: testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: testing/testing.md:127 +msgid "" +msgstr "" + +#: testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: testing/testing.md:139 +#: testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: testing/testing.md:154 +msgid "" +msgstr "" + +#: testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: testing/testing.md:165 +msgid "" +msgstr "" + +#: testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: testing/testing.md:179 +msgid "" +msgstr "" + +#: testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: testing/testing.md:184 +msgid "" +msgstr "" + +#: testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: testing/testing.md:239 +msgid "" +msgstr "" + +#: testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: testing/testing.md:246 +msgid "" +msgstr "" + +#: testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: testing/testing.md:267 +msgid "" +msgstr "" + +#: testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: testing/testing.md:270 +msgid "" +msgstr "" + +#: testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: testing/testing.md:297 +msgid "" +msgstr "" + +#: testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: testing/testing.md:325 +msgid "" +msgstr "" + +#: testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: testing/testing.md:334 +msgid "" +msgstr "" + +#: testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: testing/testing.md:353 +msgid "" +msgstr "" + +#: testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: testing/testing.md:360 +msgid "" +msgstr "" + +#: testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: testing/testing.md:369 +msgid "" +msgstr "" + +#: testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: testing/testing.md:395 +msgid "" +msgstr "" + +#: testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: testing/testing.md:467 +msgid "" +msgstr "" + +#: testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: testing/testing.md:480 +msgid "" +msgstr "" + +#: testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: testing/testing.md:516 +msgid "" +msgstr "" + +#: testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: testing/testing.md:523 +msgid "" +msgstr "" + +#: testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: testing/testing.md:537 +msgid "" +msgstr "" + +#: testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: testing/testing.md:550 +msgid "" +msgstr "" + +#: testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: testing/testing.md:557 +msgid "" +msgstr "" + +#: testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: testing/testing.md:574 +msgid "" +msgstr "" + +#: testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: testing/testing.md:579 +msgid "" +msgstr "" + +#: testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: testing/testing.md:618 +msgid "" +msgstr "" + +#: testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: testing/testing.md:627 +msgid "" +msgstr "" + +#: testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: testing/testing.md:632 +msgid "" +msgstr "" + +#: testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: testing/testing.md:643 +msgid "" +msgstr "" + +#: testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: testing/testing.md:655 +msgid "" +msgstr "" + +#: testing/testing.md:656 +# header +msgid "## What to learn next" +msgstr "" + +#: testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: testing/testing.md:660 +msgid "" +msgstr "" + +#: testing/testing.md:661 +# header +msgid "## Further reading" +msgstr "" + +#: testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: testing/testing.md:665 +msgid "" +msgstr "" + +#: testing/testing.md:666 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: testing/testing.md:700 +msgid "" +msgstr "" + +#: testing/testing.md:701 +# header +msgid "## Bibliography" +msgstr "" + +#: testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:705 +#: testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: testing/testing.md:726 +#: testing/testing.md:731 +#: testing/testing.md:737 +#: testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + diff --git a/book/content/po/testing.zh_CN.po b/book/content/po/testing.zh_CN.po new file mode 100644 index 00000000000..18a8081da28 --- /dev/null +++ b/book/content/po/testing.zh_CN.po @@ -0,0 +1,2007 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: testing/testing.md:1 +# header +msgid "# Testing" +msgstr "" + +#: testing/testing.md:3 +msgid "| Prerequisite | Importance |" +msgstr "" + +#: testing/testing.md:4 +msgid "| -------------|------------|" +msgstr "" + +#: testing/testing.md:5 +msgid "| [Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Necessary |" +msgstr "" + +#: testing/testing.md:7 +# header +msgid "## Table of contents" +msgstr "" + +#: testing/testing.md:9 +# ordered list +msgid "1. [Summary](#Summary)" +msgstr "" + +#: testing/testing.md:10 +# ordered list +msgid "2. [How this will help you/ why this is useful](#How_this_will_help_you_why_this_is_useful)" +msgstr "" + +#: testing/testing.md:11 +msgid " 1. [The advantages of testing for research](#The_advantages_of_testing_for_research)" +msgstr "" + +#: testing/testing.md:12 +# ordered list +msgid "3. [General guidance and good practice for testing](#General_guidance_and_good_practice_for_testing)" +msgstr "" + +#: testing/testing.md:13 +msgid " 1. [Write tests. Any tests.](#Write_tests_any_tests)" +msgstr "" + +#: testing/testing.md:14 +msgid " 2. [Run the tests](#Run_the_tests)" +msgstr "" + +#: testing/testing.md:15 +msgid " 3. [Consider how long it takes your tests to run](#Consider_how_long_it_takes_your_tests_to_run)" +msgstr "" + +#: testing/testing.md:16 +msgid " 4. [Document the tests and how to run them](#Document_the_tests_and_how_to_run_them)" +msgstr "" + +#: testing/testing.md:17 +msgid " 5. [Test realistic cases](#Test_realistic_cases)" +msgstr "" + +#: testing/testing.md:18 +msgid " 6. [Use a testing framework](#Use_a_testing_framework)" +msgstr "" + +#: testing/testing.md:19 +msgid " 7. [Aim to have a good code coverage](#Aim_to_have_a_good_code_coverage)" +msgstr "" + +#: testing/testing.md:20 +msgid " 8. [Use test doubles/mocking where appropriate](#Use_test_doubles_stubs_mocking_where_appropriate)" +msgstr "" + +#: testing/testing.md:21 +msgid " 9. [Testing stochastic code](#Testing_stochastic_code)" +msgstr "" + +#: testing/testing.md:22 +msgid " 1. [Use random number seeds](#Use_random_number_seeds)" +msgstr "" + +#: testing/testing.md:23 +msgid " 2. [Measure the distribution of results](#Measure_the_distribution_of_results)" +msgstr "" + +#: testing/testing.md:24 +msgid " 10. [Tests that are difficult to quantify](#Tests_that_are_difficult_to_quantify)" +msgstr "" + +#: testing/testing.md:25 +msgid " 11. [Testing if non-integer numbers are equal](#Testing_if_non_integer_numbers_are_equal)" +msgstr "" + +#: testing/testing.md:26 +msgid " 1. [When 0.1 + 0.2 does not equal 0.3](#When_point_1_plus_point_2_does_not_equal_point_3)" +msgstr "" + +#: testing/testing.md:27 +msgid " 2. [Equality in a floating point world](#Equality_in_a_floating_point_world)" +msgstr "" + +#: testing/testing.md:28 +# ordered list +msgid "4. [Types of tests](#Types_of_tests)" +msgstr "" + +#: testing/testing.md:29 +msgid " 1. [Level summary](#Level_summary)" +msgstr "" + +#: testing/testing.md:30 +# ordered list +msgid "5. [Smoke testing](#Smoke_testing)" +msgstr "" + +#: testing/testing.md:31 +# ordered list +msgid "6. [Unit tests](#Unit_tests)" +msgstr "" + +#: testing/testing.md:32 +msgid " 1. [Benefits of unit testing](#Benefits_of_unit_testing)" +msgstr "" + +#: testing/testing.md:33 +msgid " 2. [Unit testing tips](#Unit_testing_tips)" +msgstr "" + +#: testing/testing.md:34 +# ordered list +msgid "7. [Integration testing](#Integration_testing)" +msgstr "" + +#: testing/testing.md:35 +msgid " 1. [Approaches](#Approaches)" +msgstr "" + +#: testing/testing.md:36 +msgid " 2. [Integration testing tips](#Integration_testing_tips)" +msgstr "" + +#: testing/testing.md:37 +# ordered list +msgid "8. [System tests](#System_tests)" +msgstr "" + +#: testing/testing.md:38 +msgid " 1. [System testing tips](#System_testing_tips)" +msgstr "" + +#: testing/testing.md:39 +# ordered list +msgid "9. [Acceptance testing](#Acceptance_testing)" +msgstr "" + +#: testing/testing.md:40 +# ordered list +msgid "10. [Regression testing](#Regression_testing)" +msgstr "" + +#: testing/testing.md:41 +msgid " 1. [Limitations](#Limitations)" +msgstr "" + +#: testing/testing.md:42 +# ordered list +msgid "11. [Runtime testing](#Runtime_testing)" +msgstr "" + +#: testing/testing.md:43 +# ordered list +msgid "12. [Test driven development](#Test_driven_development)" +msgstr "" + +#: testing/testing.md:44 +# ordered list +msgid "13. [Checklist](#Checklist)" +msgstr "" + +#: testing/testing.md:45 +msgid " 1. [Writing tests](#Writing_tests)" +msgstr "" + +#: testing/testing.md:46 +msgid " 2. [Good practice checks](#Good_practice_checks)" +msgstr "" + +#: testing/testing.md:47 +# ordered list +msgid "14. [What to learn next](#What_to_learn_next)" +msgstr "" + +#: testing/testing.md:48 +# ordered list +msgid "15. [Further reading](#Further_reading)" +msgstr "" + +#: testing/testing.md:49 +# ordered list +msgid "16. [Definitions/glossary](#Definitions_glossary)" +msgstr "" + +#: testing/testing.md:50 +# ordered list +msgid "17. [Bibliography](#Bibliography)" +msgstr "" + +#: testing/testing.md:52 +msgid "" +msgstr "" + +#: testing/testing.md:53 +# header +msgid "## Summary" +msgstr "" + +#: testing/testing.md:55 +msgid "Researcher-written code now forms a part of a huge portion of research, and if there are mistakes in the code the results may be partly or entirely unreliable. Testing code thoroughly and frequently is vital to ensure reliable, reproducible research. This chapter will cover general guidance for writing tests, and describes a number of different kinds of testing, their uses, and how to go about implementing them." +msgstr "" + +#: testing/testing.md:57 +msgid "" +msgstr "" + +#: testing/testing.md:58 +# header +msgid "## How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:60 +msgid "Here's a couple of examples of why should write tests:" +msgstr "" + +#: testing/testing.md:62 +msgid "![testing_motivation_1](../figures/testing_motivation_1.png)" +msgstr "" + +#: testing/testing.md:64 +msgid "![testing_motivation_2](../figures/testing_motivation_2.png)" +msgstr "" + +#: testing/testing.md:66 +msgid "It is very, very easy to make mistakes when coding. A single misplaced character can cause a program's output to be entirely wrong. One of the examples above was caused by a plus sign which should have been a minus. Another was caused by one piece of code working in meters while a piece of code written by another researcher worked in feet. *Everyone* makes mistakes, and in research the results can be catastrophic. Careers can be damaged/ended, vast sums of research funds can be wasted, and valuable time may be lost to exploring incorrect avenues. This is why tests are vital." +msgstr "" + +#: testing/testing.md:68 +msgid "Even if problems in a program are caught before research is published it can be difficult to figure out what results are contaminated and must be re-done. This represents a huge loss of time and effort. Catching these problems as early as possible minimises the amount of work it takes to fix them, and for most researchers time is by far their most scarce resource. You should not skip writing tests because you are short on time, you should write tests *because* you are short on time. Researchers cannot afford to have months or years of work go down the drain, and they can't afford to repeatedly manually check every little detail of a program that might be hundreds or hundreds of thousands of lines long. Writing tests to do it for you is the time-saving option, and it's the safe option." +msgstr "" + +#: testing/testing.md:70 +msgid "As researchers write code they generally do some tests as they go along, often by adding in print statements and checking the output. However, these tests are often thrown away as soon as they pass and are no longer present to check what they were intended to check. It is comparatively very little work to place these tests in functions and keep them so they can be run at any time in the future. The additional labour is minimal, the time saved and safeguards provided are invaluable. Further, by formalising the testing process into a suite of tests that can be run independently and automatically, you provide a much greater degree of confidence that the software behaves correctly and increase the likelihood that defects will be found." +msgstr "" + +#: testing/testing.md:72 +msgid "Testing also affords researchers much more peace of mind when working on/improving a project. After changing their code a researcher will want to check that their changes or fixes have not broken anything. Providing researchers with a fail-fast environment allows the rapid identification of failures introduced by changes to the code. The alternative, of the researcher writing and running whatever small tests they have time for is far inferior to a good testing suite which can thoroughly check the code." +msgstr "" + +#: testing/testing.md:74 +msgid "Another benefit of writing tests is that it typically forces a researcher to write cleaner, more modular code as such code is far easier to write tests for, leading to an improvement in code quality. Good quality code is far easier (and altogether more pleasant) to work with than tangled rat's nests of code I'm sure we've all come across (and, let's be honest, written). This point is expanded upon in the section on [unit tests](#Unit_tests)." +msgstr "" + +#: testing/testing.md:76 +msgid "" +msgstr "" + +#: testing/testing.md:77 +# header +msgid "### The advantages of testing for research" +msgstr "" + +#: testing/testing.md:79 +msgid "As well as advantaging individual researchers testing also benefits research as a whole. It makes research more reproducible by answering the question \"how do we even know this code works\". If tests are never saved, just done and deleted the proof cannot be reproduced easily." +msgstr "" + +#: testing/testing.md:81 +msgid "Testing also helps prevent valuable grant money being spent on projects that may be partly or wholly flawed due to mistakes in the code. Worse if mistakes are not at found and the work is published any subsequent work that builds upon the project will be similarly flawed." +msgstr "" + +#: testing/testing.md:83 +msgid "Perhaps the cleanest expression of why testing is important for research as a whole can be found in the [Software Sustainability Institute](https://www.software.ac.uk/) slogan: better software better research." +msgstr "" + +#: testing/testing.md:85 +msgid "" +msgstr "" + +#: testing/testing.md:86 +# header +msgid "## General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:88 +msgid "There are a number of [different kinds](#Types_of_tests) of testing which each have best practice specific to them. Nevertheless there is some general guidance that applies to all of them, which will be outlined here." +msgstr "" + +#: testing/testing.md:90 +msgid "" +msgstr "" + +#: testing/testing.md:91 +# header +msgid "### Write tests. Any tests." +msgstr "" + +#: testing/testing.md:93 +msgid "Starting the process of writing tests can be overwhelming, especially if you have a large code base. Further to that, as mentioned, there are many kinds of tests, and implementing all of them can seem like an impossible mountain to climb. That is why the single most important piece of guidance in this chapter is as follows: **write some tests**. Testing one tiny thing in a code that's thousands of lines long is infinitely better than testing no things in a code that's thousands of lines long. You may not be able to do everything, but doing *something* is valuable." +msgstr "" + +#: testing/testing.md:95 +msgid "Do not be discouraged. Make improvements where you can, and do your best to include tests with new code you write even if it's not feasible to write tests for all the code that's already written." +msgstr "" + +#: testing/testing.md:97 +msgid "" +msgstr "" + +#: testing/testing.md:98 +# header +msgid "### Run the tests" +msgstr "" + +#: testing/testing.md:100 +msgid "The second most important piece of advice in this chapter: run the tests. Having a beautiful, perfect test suite is no use if you rarely run it. Leaving long gaps between test runs makes it more difficult to track down what has gone wrong when a test fails because a great deal in the code will have changed. Also if it's been weeks or months since tests have been run and they fail it is difficult or impossible to know what work/results that have been done in the intervening time are still valid, and which have to be thrown away as they could have been impacted by the bug." +msgstr "" + +#: testing/testing.md:102 +msgid "As such it is best to automate your testing as far as possible. If each test needs to be run individually then that boring painstaking process is likely to get neglected. This can be done by making use of a testing framework ([discussed later](#Use_a_testing_framework)). [Jenkins](https://jenkins.io) is another good tool for this. Ideally set your tests up to run at regular intervals, possibly each night." +msgstr "" + +#: testing/testing.md:104 +msgid "Consider setting up continuous integration (discussed in the continuous integration chapter) on your project. This will automatically run your tests each time you make a change to your code and, depending on the continuous integration software you use, will notify you if any of the tests fail." +msgstr "" + +#: testing/testing.md:106 +msgid "" +msgstr "" + +#: testing/testing.md:107 +# header +msgid "### Consider how long it takes your tests to run" +msgstr "" + +#: testing/testing.md:109 +msgid "Some tests, like [unit tests](#Unit_tests) only test a small piece of code and so typically are very fast. However other kinds of tests, such as [system tests](#System_tests) which test the entire code from end to end, may take a long time to run depending on the code. As such it can be obstructive to run the entire test suite after each little bit of work. In that case it is better to run lighter weight tests such as unit tests frequently, and longer tests only once per day overnight. It is also good to scale the number of each kind of tests you have in relation to how long they take to run. You should have a lot of unit tests (or other types of tests that are fast) but much fewer tests which take a long time to run." +msgstr "" + +#: testing/testing.md:111 +msgid "" +msgstr "" + +#: testing/testing.md:112 +# header +msgid "### Document the tests and how to run them" +msgstr "" + +#: testing/testing.md:114 +msgid "It is important to provide documentation that describes how to run the tests, both for yourself in case you come back to a project in the future, and for anyone else that may wish to build upon or reproduce your work. This documentation should also cover subjects such as" +msgstr "" + +#: testing/testing.md:116 +# unordered list +msgid "- Any resources, such as test dataset files that are required" +msgstr "" + +#: testing/testing.md:117 +# unordered list +msgid "- Any configuration/settings adjustments needed to run the tests" +msgstr "" + +#: testing/testing.md:118 +# unordered list +msgid "- What software (such as [testing frameworks](#Use_a_testing_framework)) need to be installed" +msgstr "" + +#: testing/testing.md:120 +msgid "Ideally, you would provide scripts to set up and configure any resources that are needed." +msgstr "" + +#: testing/testing.md:122 +msgid "" +msgstr "" + +#: testing/testing.md:123 +# header +msgid "### Test realistic cases" +msgstr "" + +#: testing/testing.md:125 +msgid "Make the cases you test as realistic as possible. If for example, you have dummy data to run tests on you should make sure that data is as similar as possible to the actual data. If your actual data is messy with a lot of null values, so should your test dataset be." +msgstr "" + +#: testing/testing.md:127 +msgid "" +msgstr "" + +#: testing/testing.md:128 +# header +msgid "### Use a testing framework" +msgstr "" + +#: testing/testing.md:130 +msgid "There are tools available to make writing and running tests easier, these are known as testing frameworks. Find one you like, learn about the features it offers, and make use of them. Common testing frameworks (and the languages they apply to) include:" +msgstr "" + +#: testing/testing.md:132 +# unordered list +msgid "- Language agnostic" +msgstr "" + +#: testing/testing.md:133 +# unordered list +msgid " - CTest, test runner for executables, bash scripts, and more. Great for legacy code hardening" +msgstr "" + +#: testing/testing.md:134 +# unordered list +msgid "- C++" +msgstr "" + +#: testing/testing.md:135 +# unordered list +msgid " - Catch" +msgstr "" + +#: testing/testing.md:136 +# unordered list +msgid " - CppTest" +msgstr "" + +#: testing/testing.md:137 +# unordered list +msgid " - Boost::Test" +msgstr "" + +#: testing/testing.md:138 +# unordered list +msgid " - google-test " +msgstr "" + +#: testing/testing.md:139 +#: testing/testing.md:500 +# unordered list +msgid "- C" +msgstr "" + +#: testing/testing.md:140 +# unordered list +msgid " - all C++ frameworks" +msgstr "" + +#: testing/testing.md:141 +# unordered list +msgid " - Check" +msgstr "" + +#: testing/testing.md:142 +# unordered list +msgid " - CUnit" +msgstr "" + +#: testing/testing.md:143 +# unordered list +msgid "- Python" +msgstr "" + +#: testing/testing.md:144 +# unordered list +msgid " - pytest (recommended)" +msgstr "" + +#: testing/testing.md:145 +# unordered list +msgid " - unittest comes with standard Python library" +msgstr "" + +#: testing/testing.md:146 +# unordered list +msgid "- R unit-tests" +msgstr "" + +#: testing/testing.md:147 +# unordered list +msgid " - testthat" +msgstr "" + +#: testing/testing.md:148 +# unordered list +msgid " - tinytest" +msgstr "" + +#: testing/testing.md:149 +# unordered list +msgid " - svUnit (works with SciViews GUI)" +msgstr "" + +#: testing/testing.md:150 +# unordered list +msgid "- Fortran unit-tests:" +msgstr "" + +#: testing/testing.md:151 +# unordered list +msgid " - funit" +msgstr "" + +#: testing/testing.md:152 +# unordered list +msgid " - pfunit (works with MPI)" +msgstr "" + +#: testing/testing.md:154 +msgid "" +msgstr "" + +#: testing/testing.md:155 +# header +msgid "### Aim to have a good code coverage" +msgstr "" + +#: testing/testing.md:157 +msgid "Code coverage is a measure of how much of your code is \"covered\" by tests. More precisely it a measure of how much of your code is run when tests are conducted. So for example, if you have a `if` statement but only test things where that if statement evaluates to \"True\" then none of the code that comes under \"False\" will be run. As a result your code coverage would be < 100% (the exact number would depend on how much code comes under the True and False cases). Code coverage doesn't include documentation like comments, so adding more documentation doesn't affect your percentages." +msgstr "" + +#: testing/testing.md:159 +msgid "As [mentioned](#Write_tests_any_tests) any tests are an improvement over no tests. Nevertheless it is good to at least aspire to having your code coverage as high as feasible." +msgstr "" + +#: testing/testing.md:161 +msgid "Most programming languages have tools either built into them, or that can be imported, or as part of testing frameworks, which automatically measure code coverage. There's also a nice little [bot](https://codecov.io/) for measuring code coverage available too." +msgstr "" + +#: testing/testing.md:163 +msgid "**Pitfall: The illusion of good coverage.** In some instances, the same code can and probably should be tested in multiple ways. For example, coverage can quickly increase on code that applies \"sanity check\" tests to its output ([see below](#tests-that-are-difficult-to-quantify)), but this doesn't preclude the risk that the code is producing the broadly right answer for the wrong reasons. In general, the best tests are those that isolate the smaller rather than larger chunks of coherent code, and so pick out individual steps of logic. Try to be guided by thinking about the possible things that might happen to a particular chunk of code in the execution of the whole, and test these individual cases. Often, this will result in the same code being tested multiple times - this is a good thing!" +msgstr "" + +#: testing/testing.md:165 +msgid "" +msgstr "" + +#: testing/testing.md:166 +# header +msgid "### Use test doubles/stubs/mocking where appropriate" +msgstr "" + +#: testing/testing.md:168 +msgid "If a test fails it should be constructed such that is as easy to trace the source of the failure as possible. This becomes problematic if a piece of code you want to test unavoidably depends on other things. For example if a test for a piece of code that interacts with the web fails that could be because the code has a bug *or* there is a problem with the internet connection. Similarly if a test for a piece of code that uses an object fails it could be because there is a bug in the code being tested, or a problem with the object (which should be tested by its own, separate tests). These dependencies should be eliminated from tests, if possible. This can be done via using test replacements (test doubles) in the place of the real dependencies. Test doubles can be classified as follows:" +msgstr "" + +#: testing/testing.md:170 +# unordered list +msgid "- A dummy object is passed around but never used, meaning its methods are never called. Such an object can for example be used to fill the parameter list of a method." +msgstr "" + +#: testing/testing.md:171 +# unordered list +msgid "- Fake objects have working implementations, but are usually simplified. For example, they use an in memory database and not a real database." +msgstr "" + +#: testing/testing.md:172 +# unordered list +msgid "- A stub is an partial implementation for an interface or class with the purpose of using an instance of this stub during testing. Stubs usually don’t respond to anything outside what’s programmed in for the test. Stubs may also record information about calls." +msgstr "" + +#: testing/testing.md:173 +# unordered list +msgid "- A mock object is a dummy implementation for an interface or a class in which you define the output of certain method calls. Mock objects are configured to perform a certain behaviour during a test. They typically record the interaction with the system and tests can validate that." +msgstr "" + +#: testing/testing.md:175 +msgid "Test doubles can be passed to other objects which are tested." +msgstr "" + +#: testing/testing.md:177 +msgid "You can create mock objects manually (via code) or use a mock framework to simulate these classes. Mock frameworks allow you to create mock objects at runtime and define their behaviour. The classical example for a mock object is a data provider. In production an implementation to connect to the real data source is used. But for testing a mock object simulates the data source and ensures that the test conditions are always the same." +msgstr "" + +#: testing/testing.md:179 +msgid "" +msgstr "" + +#: testing/testing.md:180 +# header +msgid "### Testing stochastic code" +msgstr "" + +#: testing/testing.md:182 +msgid "Sometimes code contains an element of randomness, a common example being code that makes use of [Monte Carlo methods](https://en.wikipedia.org/wiki/Monte_Carlo_method). Testing this kind of code can be very difficult because if it is run multiple times it will generate different answers, all of which may be \"right\", even is it contains no bugs. There are two main ways to tackle testing stochastic code:" +msgstr "" + +#: testing/testing.md:184 +msgid "" +msgstr "" + +#: testing/testing.md:185 +# header +msgid "#### Use random number seeds" +msgstr "" + +#: testing/testing.md:187 +msgid "Random number seeds are a little difficult to explain so here's an example. Here's a little Python script that prints three random numbers." +msgstr "" + +#: testing/testing.md:188 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:197 +msgid "This script has no bugs but if you run it repeatedly you will get different answers each time. Now let's set a random number seed." +msgstr "" + +#: testing/testing.md:198 +# code block +msgid "```\n" +"import random\n" +"\n" +"# Set a random number seed\n" +"random.seed(1)\n" +"\n" +"# Print three random numbers\n" +"print(random.random())\n" +"print(random.random())\n" +"print(random.random())\n" +"```" +msgstr "" + +#: testing/testing.md:210 +msgid "Now if you run this script it outputs" +msgstr "" + +#: testing/testing.md:211 +# code block +msgid "```\n" +"0.134364244112\n" +"0.847433736937\n" +"0.763774618977\n" +"```" +msgstr "" + +#: testing/testing.md:217 +msgid "and every time you run this script you will get the *same* output, it will print the *same* three random numbers. If the random number seed is changed you will get a different three random numbers:" +msgstr "" + +#: testing/testing.md:219 +# code block +msgid "```\n" +"0.956034271889\n" +"0.947827487059\n" +"0.0565513677268\n" +"```" +msgstr "" + +#: testing/testing.md:224 +msgid "but again you will get those same numbers every time the script is run in the future." +msgstr "" + +#: testing/testing.md:226 +msgid "Random number seeds are a way of making things reliably random. However a risk with tests that depend on random number seeds is they can be brittle. Say you have a function structured something like this:" +msgstr "" + +#: testing/testing.md:227 +# code block +msgid "```\n" +"def my_function()\n" +"\n" +" a = calculation_that_uses_two_random_numbers()\n" +"\n" +" b = calculation_that_uses_five_random_numbers()\n" +"\n" +" c = a + b\n" +"```" +msgstr "" + +#: testing/testing.md:237 +msgid "If you set the random number seed you will always get the same value of `c`, so it can be tested. But, say the model is changed and the function that calculates `a` uses a different number of random numbers that it did previously. Now not only will `a` be different but `b` will be too, because as shown above the random numbers outputted given a random number seed are in a fixed order. As a result the random numbers produced to calculate `b` will have changed. This can lead to tests failing when there is in fact no bug." +msgstr "" + +#: testing/testing.md:239 +msgid "" +msgstr "" + +#: testing/testing.md:240 +# header +msgid "#### Measure the distribution of results" +msgstr "" + +#: testing/testing.md:242 +msgid "Another way to test code with a random output is to run it many times and test the distribution of the results. Perhaps the result may fluctuate a little, but is always expected around 10 within some tolerance. That can be tested. The more times the code is run the more reliable the average and so the result. However the more times you run a piece of code the longer it will take your tests to run, which may make tests prohibitively time-consuming to conduct if a reliable result is to be obtained. Furthermore, there will always be an element of uncertainty and if the random numbers happen to fall in a certain way you may get result outside of the expected tolerance even if the code is correct." +msgstr "" + +#: testing/testing.md:244 +msgid "Both of these approaches to testing stochastic code can still be very useful, but it is important to also be aware of their potential pitfalls." +msgstr "" + +#: testing/testing.md:246 +msgid "" +msgstr "" + +#: testing/testing.md:247 +# header +msgid "### Tests that are difficult to quantify" +msgstr "" + +#: testing/testing.md:249 +msgid "Sometimes (particularly in research) the outputs of code are tested according to whether they \"look\" right. For example say we have a code modelling the water levels in a reservoir over time. The result may look like this:" +msgstr "" + +#: testing/testing.md:251 +msgid "![eyeball_test_1](../figures/eyeball_test_1.jpg)" +msgstr "" + +#: testing/testing.md:253 +msgid "On a day with rain it might look like this:" +msgstr "" + +#: testing/testing.md:255 +msgid "![eyeball_test_2](../figures/eyeball_test_2.jpg)" +msgstr "" + +#: testing/testing.md:257 +msgid "and on a dry day it might look like this:" +msgstr "" + +#: testing/testing.md:259 +msgid "![eyeball_test_3](../figures/eyeball_test_3.jpg)" +msgstr "" + +#: testing/testing.md:261 +msgid "All of these outputs look very different but are valid. However, if a researcher sees a result like this:" +msgstr "" + +#: testing/testing.md:263 +msgid "![eyeball_test_error](../figures/eyeball_test_error.jpg)" +msgstr "" + +#: testing/testing.md:265 +msgid "they could easily conclude there is a bug as a lake is unlikely to triple it's volume and then lose it again in the space of a few hours. \"Eyeballing\" tests like these are time consuming as they must be done by a human. However the process can be partially or fully automated by creating basic \"sanity checks\". For example the water level at one time should be within, say, 10% of the water level at the previous time step. Another check could be that there are no negative values, as a lake can't be -30% full. These sort of tests can't cover every way something can be visibly wrong, but they are much easier to automate and will suffice for most cases." +msgstr "" + +#: testing/testing.md:267 +msgid "" +msgstr "" + +#: testing/testing.md:268 +# header +msgid "### Testing if non-integer numbers are equal" +msgstr "" + +#: testing/testing.md:270 +msgid "" +msgstr "" + +#: testing/testing.md:271 +# header +msgid "#### When 0.1 + 0.2 does not equal 0.3" +msgstr "" + +#: testing/testing.md:273 +msgid "There is a complication with testing if the answer a piece of code outputs is equal to the expected answer when the numbers are not integers. Let's look at this Python example, but note that this problem is not unique to Python." +msgstr "" + +#: testing/testing.md:275 +msgid "If we assign 0.1 to `a` and 0.2 to `b` and print their sum, we get 0.3, as expected." +msgstr "" + +#: testing/testing.md:276 +# code block +msgid "```\n" +">>> a = 0.1\n" +">>> b = 0.2\n" +">>> print(a + b)\n" +"0.3\n" +"```" +msgstr "" + +#: testing/testing.md:283 +msgid "If, however, we compare the result of `a` plus `b` to 0.3 we get False." +msgstr "" + +#: testing/testing.md:284 +# code block +msgid "```\n" +">>> print(a + b == 0.3)\n" +"False\n" +"```" +msgstr "" + +#: testing/testing.md:289 +msgid "If we show the value of `a` plus `b` directly, we can see there is a subtle margin of error." +msgstr "" + +#: testing/testing.md:290 +# code block +msgid "```\n" +">>> a + b\n" +"0.30000000000000004\n" +"```" +msgstr "" + +#: testing/testing.md:295 +msgid "This is because floating point numbers are approximations of real numbers. The result of floating point calculations can depend upon the compiler or interpreter, processor or system architecture and number of CPUs or processes being used. Obviously this can present a major obstacle for writing tests." +msgstr "" + +#: testing/testing.md:297 +msgid "" +msgstr "" + +#: testing/testing.md:298 +# header +msgid "#### Equality in a floating point world" +msgstr "" + +#: testing/testing.md:300 +msgid "When comparing floating point numbers for equality, we have to compare to within a given tolerance, alternatively termed a threshold or delta. For example, we might consider the calculated and expected values of some number to be equal if the absolute value of their difference is within the absolute value of our tolerance." +msgstr "" + +#: testing/testing.md:302 +msgid "Many testing frameworks provide functions for comparing equality of floating point numbers to within a given tolerance. For example for the framework pytest:" +msgstr "" + +#: testing/testing.md:303 +# code block +msgid "```\n" +"import pytest\n" +"\n" +"a = 0.1\n" +"b = 0.2\n" +"c = a + b\n" +"assert c == pytest.approx(0.3)\n" +"```" +msgstr "" + +#: testing/testing.md:312 +msgid "this passes, but if the 0.3 was changed to 0.4 it would fail." +msgstr "" + +#: testing/testing.md:314 +msgid "Unit test frameworks for other languages also often provide similar functions:" +msgstr "" + +#: testing/testing.md:316 +# unordered list +msgid "- Cunit for C: CU_ASSERT_DOUBLE_EQUAL(actual, expected, granularity)" +msgstr "" + +#: testing/testing.md:317 +# unordered list +msgid "- CPPUnit for C++: CPPUNIT_ASSERT_DOUBLES_EQUAL(expected, actual, delta)" +msgstr "" + +#: testing/testing.md:318 +# unordered list +msgid "- googletest for C++: ASSERT_NEAR(val1, val2, abs_error)" +msgstr "" + +#: testing/testing.md:319 +# unordered list +msgid "- FRUIT for Fortran: subroutine assert_eq_double_in_range_(var1, var2, delta, message)" +msgstr "" + +#: testing/testing.md:320 +# unordered list +msgid "- JUnit for Java: org.junit.Assert.assertEquals(double expected, double actual, double delta)" +msgstr "" + +#: testing/testing.md:321 +# unordered list +msgid "- testthat for R:" +msgstr "" + +#: testing/testing.md:322 +# unordered list +msgid " - expect_equal(actual, expected, tolerance=DELTA) - absolute error within DELTA" +msgstr "" + +#: testing/testing.md:323 +# unordered list +msgid " - expect_equal(actual, expected, scale=expected, tolerance=DELTA) - relative error within DELTA" +msgstr "" + +#: testing/testing.md:325 +msgid "" +msgstr "" + +#: testing/testing.md:326 +# header +msgid "## Types of tests" +msgstr "" + +#: testing/testing.md:328 +msgid "There are a number of different kinds of tests, which will be discussed here." +msgstr "" + +#: testing/testing.md:330 +msgid "Firstly there are positive tests and negative tests. Positive tests check that something works, for example testing that a function that multiplies some numbers together outputs the correct answer. Negative tests check that something generates an error when it should. For example nothing can go quicker than the speed of light, so a plasma physics simulation code may contain a test that an error is outputted if there are any particles faster than this, as it indicates there is a deeper problem in the code." +msgstr "" + +#: testing/testing.md:332 +msgid "In addition to these two kinds of tests there are also different levels of tests which test different aspects of a project. These levels are outlined [below](#Level_summary) and both positive and negative tests can be present at any of these levels. A thorough test suite will contain tests at all of these levels (though some levels will need very few)." +msgstr "" + +#: testing/testing.md:334 +msgid "" +msgstr "" + +#: testing/testing.md:335 +# header +msgid "### Level summary" +msgstr "" + +#: testing/testing.md:337 +msgid "[Smoke testing](#Smoke_testing): Very brief initial checks that ensures the basic requirements required to run the project hold. If these fail there is no point proceeding to additional levels of testing until they are fixed." +msgstr "" + +#: testing/testing.md:339 +msgid "[Unit testing](#Unit_tests): A level of the software testing process where individual units of a software are tested. The purpose is to validate that each unit of the software performs as designed." +msgstr "" + +#: testing/testing.md:341 +msgid "[Integration testing](#Integration_testing): A level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:343 +msgid "[System testing](#System_tests): A level of the software testing process where a complete, integrated system is tested. The purpose of this test is to evaluate whether the system as a whole gives the correct outputs for given inputs." +msgstr "" + +#: testing/testing.md:345 +msgid "[Acceptance testing](#Acceptance_testing): A level of the software testing process where a system is tested for acceptability. The purpose of this test is to evaluate the system's compliance with the project requirements and assess whether it is acceptable for the purpose." +msgstr "" + +#: testing/testing.md:347 +msgid "Here's an analogy: during the process of manufacturing a ballpoint pen, the cap, the body, the tail, the ink cartridge and the ballpoint are produced separately and unit tested separately. When two or more units are ready, they are assembled and integration testing is performed, for example a test to check the cap fits on the body. When the complete pen is integrated, system testing is performed to check it can be used to write like any pen should. Acceptance testing could be a check to ensure the pen is the colour the customer ordered." +msgstr "" + +#: testing/testing.md:349 +msgid "There is also another kind of testing called regression testing. Regression testing is a type of testing that can be performed at any of the four main levels and compares the results of tests before and after a change is made to the code, and gives an error if these are different." +msgstr "" + +#: testing/testing.md:351 +msgid "These different types of tests will now be discussed in more detail." +msgstr "" + +#: testing/testing.md:353 +msgid "" +msgstr "" + +#: testing/testing.md:354 +# header +msgid "## Smoke testing" +msgstr "" + +#: testing/testing.md:356 +msgid "Smoke tests (also known as build verification tests) are a special kind of initial checks designed to ensure very basic functionality as well as some basic implementation and environmental assumptions. Smoke tests are generally run at the very start of each testing cycle as a sanity check before running a more complete test suite." +msgstr "" + +#: testing/testing.md:358 +msgid "The idea behind this type of test is to help to catch big red flags in an implementation and to bring attention to problems that might indicate that further testing is either not possible or not worthwhile. Normally, the tester is asking whether any components are so obviously or badly broken that the build is not worth testing or some components are broken in obvious ways that suggest a corrupt build or some critical fixes that are the primary intent of the new build didn't work. Smoke tests are not very extensive, but should be extremely quick. If a change to a project causes it to fail a smoke test, its an early signal that core assertions were broken and that you should not devote any more time to testing until the problem is resolved. For example if a function that reads in the data a project requires to run is broken there's no point testing any further before that's fixed. The typical result of a failed smoke test is rejection of the build (testing of the build stops) not just a new set of bug reports." +msgstr "" + +#: testing/testing.md:360 +msgid "" +msgstr "" + +#: testing/testing.md:361 +# header +msgid "## Unit tests" +msgstr "" + +#: testing/testing.md:363 +msgid "Unit tests are responsible for testing individual elements of code in an isolated and highly targeted way. The functionality of individual functions and classes are tested on their own. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. In procedural programming, a unit may be an individual program, function or procedure. In object-oriented programming the smallest unit is typically a method. It usually has one or a few inputs and usually a single output. Any external dependencies should be replaced with [stub or mock implementations](#Use_test_doubles_stubs_mocking_where_appropriate) to focus the test completely on the code in question." +msgstr "" + +#: testing/testing.md:365 +msgid "Unit tests are essential to test the correctness of individual code components for internal consistency and correctness before they are placed in more complex contexts. The limited extent of the tests and the removal of dependencies makes it easier to hunt down the cause of any defects. It also is the best time to test a variety of inputs and code branches that might be difficult to hit later on. For example system tests are often time consuming to run and it will likely be impractical to have system tests for every possible path through a code that has more than a few conditional statements. Unit tests are smaller, faster, and so it is more practical to cover all possible cases with them." +msgstr "" + +#: testing/testing.md:367 +msgid "Often, after any smoke tests, unit tests are the first tests that are run when any changes are made." +msgstr "" + +#: testing/testing.md:369 +msgid "" +msgstr "" + +#: testing/testing.md:370 +# header +msgid "### Benefits of unit testing" +msgstr "" + +#: testing/testing.md:372 +msgid "If a researcher makes a change to a piece of code or how it is run then how can they be sure that doing so has not broken something? They may run a few tests, but without testing every small piece of code individually how can they be certain? Unit testing gives researchers that certainty, and allows them to be confident when changing and maintaining their code." +msgstr "" + +#: testing/testing.md:374 +msgid "Here's a little example. Say a researcher has a small function that does one simple thing (here only a single line for brevity). In this example this will be raising a number to the 5th power:" +msgstr "" + +#: testing/testing.md:375 +# code block +msgid "```\n" +"def take_fifth_power(x):\n" +" result = x * x * x * x * x\n" +" return result\n" +"```" +msgstr "" + +#: testing/testing.md:381 +msgid "The unit test for this function could look like this:" +msgstr "" + +#: testing/testing.md:382 +# code block +msgid "```\n" +"def test_take_fifth_power():\n" +" assert take_fifth_power(1.5) == 7.59375\n" +"```" +msgstr "" + +#: testing/testing.md:387 +msgid "So it checks that the correct result is outputted for a given input. If not the test will fail. The researcher carries on with their work. In the middle of it they decide to tidy up this function, multiplying the number five times like this is a bit crude. They change the `result = x * x * x * x * x` line to `result = x * 5`. Next time they run their unit tests, this test will fail, because they just made a mistake. Maybe they needed a coffee, maybe their finger slipped, maybe their coworker shot them in the ear with a nerf dart and distracted them, but when they were tidying up this function they should have written `result = x ** 5` *not* `result = x * 5`. The failed test will flag up the mistake and it can quickly be corrected. If a mistake like this went unobserved it could lead to serious errors in the researcher's work." +msgstr "" + +#: testing/testing.md:389 +msgid "So unit testing leads to more reliable code, but there are other benefits too. Firstly it makes development faster by making bugs easier to find. Larger-scale tests which test large chunks of code (while still useful) have the disadvantage that if they fail it is difficult to pinpoint the source of the bug. Because unit tests by their very definition test small pieces of code they help developers find the cause of a bug much more quickly than higher-level tests or code with no tests at all. Unit tests also make fixing bugs faster and easier because they catch bugs early while they only impact small individual units. If bugs are not detected early via unit tests then it may be a long time before they are discovered, impacting later work that built on the faulty code. This means much more code is at risk and fixing the bug is more time consuming." +msgstr "" + +#: testing/testing.md:391 +msgid "The other major benefit of unit testing is that it strongly incentivises researchers to write modular code because modular code is far easier to write unit tests for. Modular code is code that is broken up into manageable chunks which each accomplish simple tasks. This is typically achieved by dividing the code into functions and groups of functions. In contrast a script which is just one long continuous series of lines which produces a result is highly non-modular." +msgstr "" + +#: testing/testing.md:393 +msgid "Modular code is much easier to reuse, for example if a researcher has a individual function that does some Useful Thing and in a future project they need to do that thing again it is trivial to copy or import the function. In contrast if the code that does this Useful Thing is entwined with a great deal of other code in a long script it is much harder to separate it out for re-use." +msgstr "" + +#: testing/testing.md:395 +msgid "" +msgstr "" + +#: testing/testing.md:396 +# header +msgid "### Unit testing tips" +msgstr "" + +#: testing/testing.md:398 +# unordered list +msgid "- Many testing frameworks have tools specifically geared towards writing and running unit tests." +msgstr "" + +#: testing/testing.md:399 +# unordered list +msgid "- Isolate the development environment from the test environment." +msgstr "" + +#: testing/testing.md:400 +# unordered list +msgid "- Write test cases that are independent of each other. For example, if a unit A utilises the result of another unit B supplies you should test unit A with a [test double](#Use_test_doubles_stubs_mocking_where_appropriate), rather than actually calling the unit B. If you don't do this your test failing may be due to a fault in either unit A *or* unit B, making the bug harder to trace." +msgstr "" + +#: testing/testing.md:401 +# unordered list +msgid "- Aim at covering all paths through a unit. Pay particular attention to loop conditions." +msgstr "" + +#: testing/testing.md:402 +# unordered list +msgid "- In addition to writing cases to verify the behaviour, write cases to ensure the performance of the code. For example, if a function that is supposed to add two numbers takes several minutes to run there is likely a problem." +msgstr "" + +#: testing/testing.md:403 +# unordered list +msgid "- If you find a defect in your code write a test that exposes it. Why? First, you will later be able to catch the defect if you do not fix it properly. Second, your test suite is now more comprehensive. Third, you will most probably be too lazy to write the test after you have already fixed the defect. Say a code has a simple function to classify people as either adults or children:" +msgstr "" + +#: testing/testing.md:405 +# code block +msgid " ```\n" +" def adult_or_child(age):\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +" ```" +msgstr "" + +#: testing/testing.md:419 +msgid " And say this code has a unit test like this:" +msgstr "" + +#: testing/testing.md:421 +# code block +msgid " ```\n" +" def test_adult_or_child():\n" +"\n" +" # Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" return\n" +" ```" +msgstr "" + +#: testing/testing.md:433 +msgid "There's a problem with this code that isn't being tested: if a negative age is supplied it will happily classify the person as a child despite negative ages not being possible. The code should throw an error in this case. So once the bug is fixed:" +msgstr "" + +#: testing/testing.md:434 +# code block +msgid "```\n" +"def adult_or_child(age):\n" +"\n" +" # Check age is valid\n" +" if age < 0:\n" +" raise ValueError, 'Not possible to have a negative age'\n" +"\n" +" # If the age is greater or equal to 18 classify them as an adult\n" +" if age >= 18:\n" +" person_status = 'Adult'\n" +"\n" +" # If the person is not an adult classify them as a child\n" +" else:\n" +" person_status = 'Child'\n" +"\n" +" return person_status\n" +"```" +msgstr "" + +#: testing/testing.md:452 +msgid "go ahead and write a test to ensure that future changes in the code can't cause it to happen again:" +msgstr "" + +#: testing/testing.md:453 +# code block +msgid "``` \n" +"def test_adult_or_child():\n" +"\n" +" #Test that an adult is correctly classified as an adult\n" +" assert adult_or_child(22) == 'Adult'\n" +"\n" +" # Test that an child is correctly classified as a child\n" +" assert adult_or_child(5) == 'Child'\n" +"\n" +" # Test that supplying an invalid age results in an error\n" +" with pytest.raises(ValueError):\n" +" adult_or_child(-10)\n" +"```" +msgstr "" + +#: testing/testing.md:467 +msgid "" +msgstr "" + +#: testing/testing.md:468 +# header +msgid "## Integration testing" +msgstr "" + +#: testing/testing.md:470 +msgid "Integration testing is a level of software testing where individual units are combined and tested as a group. While unit tests validate the functionality of code in isolation, integration tests ensure that components cooperate when interfacing with one another. The purpose of this level of testing is to expose faults in the interaction between integrated units." +msgstr "" + +#: testing/testing.md:472 +msgid "For example, maybe a unit that reads in some data is working and passes its unit tests, and the following unit that cleans up the data once it's been read in is also working and passes its tests. However say the first unit outputs the data as (time_data, temperature_data) but the function that cleans the data expects input of the form (temperature_data, time_data). This can obviously lead to bugs. While the units are correct there in an error in their integration." +msgstr "" + +#: testing/testing.md:474 +msgid "An example of an integration test for this case could be to supply a test data file, use these functions to read it in and clean it, and check the resulting cleaned data against what would be expected. If a bug like this is present then the cleaned data outputted would be very unlikely to match the expected result, and an error would be raised." +msgstr "" + +#: testing/testing.md:476 +msgid "Integration testing is particularly important in collaborative projects where different people work on different parts of the code. If two different people complete separate units and then need to integrate then integration issues are more likely as neither may understand the other's code. A famous example of this is a multi-million dollar satellite which [crashed](https://en.wikipedia.org/wiki/Mars_Climate_Orbiter) because one piece of code outputted distance data in feet, while another assumed data in meters. This is another example of an integration issue." +msgstr "" + +#: testing/testing.md:478 +msgid "A sub type of integration testing is system integration testing. This tests the integration of systems, packages and any interfaces to external organizations (such as Electronic Data Interchange, Internet). Depending on the nature of a project system integration testing may or may not be applicable." +msgstr "" + +#: testing/testing.md:480 +msgid "" +msgstr "" + +#: testing/testing.md:481 +# header +msgid "### Approaches" +msgstr "" + +#: testing/testing.md:483 +msgid "There are several different approaches to integration testing. Big Bang is an approach to integration testing where all or most of the units are combined together and tested at one go. This approach is taken when the testing team receives the entire software in a bundle. So what is the difference between Big Bang integration testing and system testing? Well, the former tests only the interactions between the units while the latter tests the entire system." +msgstr "" + +#: testing/testing.md:485 +msgid "Top Down is an approach to integration testing where top-level sections of the code (that themselves contain many smaller units) are tested first and lower level units are tested step by step after that. So is a code can be split into the main steps A, B, and C, and each of those contain steps to complete them, and these steps may have substeps like:" +msgstr "" + +#: testing/testing.md:487 +# unordered list +msgid "- A" +msgstr "" + +#: testing/testing.md:488 +# unordered list +msgid " - A.1" +msgstr "" + +#: testing/testing.md:489 +# unordered list +msgid " - A.1.1" +msgstr "" + +#: testing/testing.md:490 +# unordered list +msgid " - A.1.2" +msgstr "" + +#: testing/testing.md:491 +# unordered list +msgid " - A.2" +msgstr "" + +#: testing/testing.md:492 +# unordered list +msgid "- B" +msgstr "" + +#: testing/testing.md:493 +# unordered list +msgid " - B.1" +msgstr "" + +#: testing/testing.md:494 +# unordered list +msgid " - B.2" +msgstr "" + +#: testing/testing.md:495 +# unordered list +msgid " - B.2.1" +msgstr "" + +#: testing/testing.md:496 +# unordered list +msgid " - B.2.2" +msgstr "" + +#: testing/testing.md:497 +# unordered list +msgid " - B.2.3" +msgstr "" + +#: testing/testing.md:498 +# unordered list +msgid " - B.3" +msgstr "" + +#: testing/testing.md:501 +# unordered list +msgid " - C.1" +msgstr "" + +#: testing/testing.md:502 +# unordered list +msgid " - C.1.1" +msgstr "" + +#: testing/testing.md:503 +# unordered list +msgid " - C.1.2" +msgstr "" + +#: testing/testing.md:504 +# unordered list +msgid " - C.2" +msgstr "" + +#: testing/testing.md:505 +# unordered list +msgid " - C.2.1" +msgstr "" + +#: testing/testing.md:506 +# unordered list +msgid " - C.2.2" +msgstr "" + +#: testing/testing.md:508 +msgid "So in the top down approach the integration between sections at the top level (A, B and C) are tested, then integration between sections at the next level (for example, A.1 -> A.2) and so on. Testing upper level units by running all the code they contain including running lower level ones can lead to upper level tests breaking due to bugs in low level units. This is undesirable, so to prevent this the lower level sections should not be run, but [test stubs](#Use_test_doubles_stubs_mocking_where_appropriate) should be used to simulate the outputs from them." +msgstr "" + +#: testing/testing.md:510 +msgid "Bottom Up is an approach to integration testing where integration between bottom level sections are tested first and upper-level sections step by step after that. Again test stubs should be used, in this case to simulate inputs from higher level sections." +msgstr "" + +#: testing/testing.md:512 +msgid "Sandwich/Hybrid is an approach to integration testing which is a combination of Top Down and Bottom Up approaches." +msgstr "" + +#: testing/testing.md:514 +msgid "Which approach you should use will depend on which best suits the nature/structure of your project." +msgstr "" + +#: testing/testing.md:516 +msgid "" +msgstr "" + +#: testing/testing.md:517 +# header +msgid "### Integration testing tips" +msgstr "" + +#: testing/testing.md:519 +# unordered list +msgid "- Ensure that you have a proper Detail Design document where interactions between each unit are clearly defined. It is difficult or impossible to perform integration testing without this information." +msgstr "" + +#: testing/testing.md:520 +# unordered list +msgid "- Make sure that each unit is unit tested and fix any bugs before you start integration testing. If there is a bug in the individual units then the integration tests will almost certainly fail even if there is no error in how they are integrated." +msgstr "" + +#: testing/testing.md:521 +# unordered list +msgid "- Use mocking/stubs where appropriate." +msgstr "" + +#: testing/testing.md:523 +msgid "" +msgstr "" + +#: testing/testing.md:524 +# header +msgid "## System tests" +msgstr "" + +#: testing/testing.md:526 +msgid "Once integration tests are performed, another level of testing called system testing can begin. System testing is a level of software testing where a complete and integrated software is tested. The tester supplies the program with input and verifies if the program's output is correct. If it is not then there is a problem somewhere in the system. Note that this does not have to be done manually, it can be automated. The purpose of these tests is to evaluate the system's compliance with the specified requirements. In many ways, system testing acts as an extension to integration testing. The focus of system tests are to make sure that groups of components function correctly as a cohesive whole." +msgstr "" + +#: testing/testing.md:527 +msgid "However, instead of focusing on the interfaces between components, system tests typically evaluate the outward functionality of a full piece of software. This set of tests ignores the constituent parts in order to gauge the composed software as a unified entity. Because of this distinction, system tests usually focus on user- or externally-accessible outputs." +msgstr "" + +#: testing/testing.md:529 +msgid "System testing can also test features of the system other than correctness. Examples include:" +msgstr "" + +#: testing/testing.md:531 +# unordered list +msgid "- Performance testing: does the program performance meet the minimum requirements? A performance test may measure how long the system takes to run in a given case." +msgstr "" + +#: testing/testing.md:532 +# unordered list +msgid "- Migration testing: does the program work when transferred to another computational environment?" +msgstr "" + +#: testing/testing.md:533 +# unordered list +msgid "- Stress/scale/load testing: testing how the program behaves when under stress, for example, when required to process very large volumes of data." +msgstr "" + +#: testing/testing.md:534 +# unordered list +msgid "- Usability testing: how user-friendly is the program (more common in commercial software, tests typically conducted by humans rather than automated)." +msgstr "" + +#: testing/testing.md:535 +# unordered list +msgid "- Recovery testing: Can the program continue if errors occur (again, more common in commercial software)." +msgstr "" + +#: testing/testing.md:537 +msgid "" +msgstr "" + +#: testing/testing.md:538 +# header +msgid "### System testing tips" +msgstr "" + +#: testing/testing.md:540 +msgid "System tests, also called end-to-end tests, run the program, well, from end to end. As such these are the most time consuming tests to run. Therefore you should only run these if all the lower-level tests (smoke, unit, integration) have already passed. If they haven't fix the issues they have detected first before wasting time running system tests." +msgstr "" + +#: testing/testing.md:542 +msgid "Because of their time-consuming nature it will also often be impractical to have enough system tests to trace every possible route through a program, especially is there are a significant number of conditional statements. Therefore you should consider the system test cases you run carefully and prioritise:" +msgstr "" + +#: testing/testing.md:544 +# unordered list +msgid "- The most common routes through a program." +msgstr "" + +#: testing/testing.md:545 +# unordered list +msgid "- The most important routes for a program. For example, the LIGO detector aims to find gravitational wave events, which are extremely rare. If there's a bug in that path through the program which monitors the detector then it's a *huge* problem." +msgstr "" + +#: testing/testing.md:546 +# unordered list +msgid "- Cases that are prone to breakage due to structural problems within the program. Though ideally it's better to just fix those problems, but cases exist where this may not be feasible." +msgstr "" + +#: testing/testing.md:548 +msgid "Because system tests can be time consuming it may be impractical to run them very regularly (such as multiple times a day after small changes in the code). Therefore it can be a good idea to run them each night (and to automate this process) so that if errors are introduced that only system testing can detect the programmer will be made of them relatively quickly." +msgstr "" + +#: testing/testing.md:550 +msgid "" +msgstr "" + +#: testing/testing.md:551 +# header +msgid "## Acceptance testing" +msgstr "" + +#: testing/testing.md:553 +msgid "Acceptance tests are one of the last tests types that are performed on software prior to delivery. Acceptance testing is used to determine whether a piece of software satisfies all of the requirements from the business or user's perspective. Does this piece of software do what it needs to do? These tests are sometimes built against the original specification." +msgstr "" + +#: testing/testing.md:555 +msgid "Because research software is typically written by the researcher that will use it (or at least with significant input from them) acceptance tests may not be necessary." +msgstr "" + +#: testing/testing.md:557 +msgid "" +msgstr "" + +#: testing/testing.md:558 +# header +msgid "## Regression testing" +msgstr "" + +#: testing/testing.md:560 +msgid "Regression testing is a style of testing that focuses on retesting after changes are made. The results of tests after the changes are compared to the results before, and errors are raised if these are different. Regression testing is intended to ensure that changes (enhancements or defect fixes) to the software have not adversely affected it. The likelihood of any code change impacting functionalities that are not directly associated with the code is always there and it is essential that regression testing is conducted to make sure that fixing one thing has not broken another. Regression testing can be performed during any level of testing (unit, integration, system, or acceptance) but it is mostly relevant during system testing. Any test can be reused, and so any test can become a regression test." +msgstr "" + +#: testing/testing.md:562 +msgid "Regression testing is obviously especially important in team working, but it is surprisingly easy to break your own code without noticing it, even if you are working on your own. And because regression testing is next to impossible to do satisfactorily by hand (it's simply too tedious), it's an obvious case for automation." +msgstr "" + +#: testing/testing.md:564 +msgid "Regression tests are written by first running the (or part of the) code for given inputs and recording the outputs. This could be done by writing input files and saving the corresponding output files. These outputs serve as the expected outputs from the program given the corresponding inputs. Regression tests are then written. Each regression test runs the code for the set of inputs. It then compares the output from the code to the expected outputs, and raises an error if these do not match." +msgstr "" + +#: testing/testing.md:566 +msgid "Regression testing approaches differ in their focus. Common examples include:" +msgstr "" + +#: testing/testing.md:568 +# unordered list +msgid "- Bug regression: We retest a specific bug that has been allegedly fixed." +msgstr "" + +#: testing/testing.md:569 +# unordered list +msgid "- Old fix regression testing: We retest several old bugs that were fixed, to see if they are back. (This is the classical notion of regression: the program has regressed to a bad state.)" +msgstr "" + +#: testing/testing.md:570 +# unordered list +msgid "- General functional regression: We retest the project broadly, including areas that worked before, to see whether more recent changes have destabilized working code." +msgstr "" + +#: testing/testing.md:571 +# unordered list +msgid "- Conversion or port testing: The program is ported to a new platform and a regression test suite is run to determine whether the port was successful." +msgstr "" + +#: testing/testing.md:572 +# unordered list +msgid "- Configuration testing: The program is run with a new device or on a new version of the operating system or in conjunction with a new application. This is like port testing except that the underlying code hasn't been changed--only the external components that the software under test must interact with." +msgstr "" + +#: testing/testing.md:574 +msgid "" +msgstr "" + +#: testing/testing.md:575 +# header +msgid "### Limitations" +msgstr "" + +#: testing/testing.md:577 +msgid "Regression tests are not guaranteed to test all parts of the code. Most importantly, regression tests do not test if the result outputted by a piece of code is *correct*, only that is has not changed. This the remit of other kinds of tests, though regression tests can serve as the starting point for introducing tests for correctness, by both the use of analytical solutions, and test functions which read output files and check the data for correctness, as defined by a researcher." +msgstr "" + +#: testing/testing.md:579 +msgid "" +msgstr "" + +#: testing/testing.md:580 +# header +msgid "## Runtime testing" +msgstr "" + +#: testing/testing.md:582 +msgid "Runtime tests are tests that run as part of the program itself. They may take the form of checks within the code, as shown below:" +msgstr "" + +#: testing/testing.md:583 +# code block +msgid "```\n" +"population = population + people_born - people_died\n" +"\n" +"// test that the population is positive\n" +"if (population < 0):\n" +" error( 'The number of people can never be negative' )\n" +"```" +msgstr "" + +#: testing/testing.md:591 +msgid "Another example of a use of runtime tests is internal checks within functions that verify that their inputs and outputs are valid, as shown below:" +msgstr "" + +#: testing/testing.md:592 +# code block +msgid "```\n" +"function add_arrays( array1, array2 ):\n" +"\n" +" // test that the arrays have the same size\n" +" if (array1.size() != array2.size()):\n" +" error( 'The arrays have different sizes!' )\n" +"\n" +" output = array1 + array2\n" +"\n" +" if (output.size() != array1.size()):\n" +" error( 'The output array has the wrong size!'' )\n" +"\n" +" return output\n" +"```" +msgstr "" + +#: testing/testing.md:607 +msgid "Advantages of runtime testing:" +msgstr "" + +#: testing/testing.md:609 +# unordered list +msgid "- Run within the program, so can catch problems caused by logic errors or edge cases." +msgstr "" + +#: testing/testing.md:610 +# unordered list +msgid "- Makes it easier to find the cause of the bug by catching problems early." +msgstr "" + +#: testing/testing.md:611 +# unordered list +msgid "- Catching problems early also helps prevent them escalating into catastrophic failures. It minimises the blast radius." +msgstr "" + +#: testing/testing.md:613 +msgid "Disadvantages of runtime testing:" +msgstr "" + +#: testing/testing.md:615 +# unordered list +msgid "- Tests can slow down the program." +msgstr "" + +#: testing/testing.md:616 +# unordered list +msgid "- What is the right thing to do if an error is detected? How should this error be reported? Exceptions are a recommended route to go with this." +msgstr "" + +#: testing/testing.md:618 +msgid "" +msgstr "" + +#: testing/testing.md:619 +# header +msgid "## Test driven development" +msgstr "" + +#: testing/testing.md:621 +msgid "One way of ensuring tests are not neglected in a project is to adopt test-driven development. This is an approach in which unit tests are written before the code. The tests thus describe a \"contract\" that the code is expected to comply with. This ensures that the code will be correct (as far as can be enforced by the testing contract) as written, and it provides a useful framework for thinking about how the code should be designed, what interfaces it should provide, and how its algorithms might work. This can be a very satisfying mental aid in developing tricky algorithms." +msgstr "" + +#: testing/testing.md:623 +msgid "Once the tests are written, the code is developed so that it passes all the associated tests. Testing the code from the outset ensures that your code is always in a releasable state (as long as it passes the tests!). Test driven development forces you to break up your code into small discrete units, to make them easier to test; the code must be modular. The benefits of this were discussed in the section on [unit testing](#Unit_tests)." +msgstr "" + +#: testing/testing.md:625 +msgid "An alternative development approach is behaviour driven development. Simply put test driven development tests \"has the thing been done correctly?\", behaviour driven development tests \"has the correct thing been done?\". It is more often used in commercial software development to focus development on making the software as simple and effective as possible for users. User experience is very rarely at the heart of code written for the purposes of research, but there are cases where such software is written with a large user-base in mind. In such cases behaviour-driven development is a path worth considering." +msgstr "" + +#: testing/testing.md:627 +msgid "" +msgstr "" + +#: testing/testing.md:628 +# header +msgid "## Checklist" +msgstr "" + +#: testing/testing.md:630 +msgid "This checklist contains a lot of items. As [mentioned](#Write_tests_any_tests) it is far better to do some of the items than none of them. Do not be discouraged if this list of tasks seems insurmountable." +msgstr "" + +#: testing/testing.md:632 +msgid "" +msgstr "" + +#: testing/testing.md:633 +# header +msgid "### Writing tests" +msgstr "" + +#: testing/testing.md:635 +# unordered list +msgid "- [ ] Write a few smoke tests." +msgstr "" + +#: testing/testing.md:636 +# unordered list +msgid "- [ ] Write unit tests for all your code units." +msgstr "" + +#: testing/testing.md:637 +# unordered list +msgid "- [ ] Write integration tests to check the integration between units." +msgstr "" + +#: testing/testing.md:638 +# unordered list +msgid "- [ ] Write a few system tests. Prioritise common and important paths through the program." +msgstr "" + +#: testing/testing.md:639 +# unordered list +msgid "- [ ] Write regression tests. Regression tests can exist at any level of testing." +msgstr "" + +#: testing/testing.md:640 +# unordered list +msgid "- [ ] If appropriate for your project write acceptance tests." +msgstr "" + +#: testing/testing.md:641 +# unordered list +msgid "- [ ] Add runtime tests into your project." +msgstr "" + +#: testing/testing.md:643 +msgid "" +msgstr "" + +#: testing/testing.md:644 +# header +msgid "### Good practice checks" +msgstr "" + +#: testing/testing.md:646 +# unordered list +msgid "- [ ] Document the tests and how to run them." +msgstr "" + +#: testing/testing.md:647 +# unordered list +msgid " - [ ] Write scripts to set up and configure any resources that are needed to run the tests." +msgstr "" + +#: testing/testing.md:648 +# unordered list +msgid "- [ ] Pick and make use of a testing framework." +msgstr "" + +#: testing/testing.md:649 +# unordered list +msgid "- [ ] Run the tests regularly." +msgstr "" + +#: testing/testing.md:650 +# unordered list +msgid " - [ ] Automate the process of running tests. Consider making use of continuous integration (see continuous integration chapter) to do this." +msgstr "" + +#: testing/testing.md:651 +# unordered list +msgid "- [ ] Check the code coverage of your tests and try to improve it." +msgstr "" + +#: testing/testing.md:652 +# unordered list +msgid "- [ ] Engage in code review with a partner." +msgstr "" + +#: testing/testing.md:655 +msgid "" +msgstr "" + +#: testing/testing.md:656 +# header +msgid "## What to learn next" +msgstr "" + +#: testing/testing.md:658 +msgid "Try reading the chapter on reproducible computational environments and then the chapter on continuous integration. The chapter on reviewing outlines how you can further strengthen your code base by adding a formal reviewing stage to your development workflow." +msgstr "" + +#: testing/testing.md:660 +msgid "" +msgstr "" + +#: testing/testing.md:661 +# header +msgid "## Further reading" +msgstr "" + +#: testing/testing.md:663 +msgid "[TutorialsPoint](https://www.tutorialspoint.com/software_testing/) has a number of useful tutorials related to testing, as does the [Turing Institute](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html). It is also worth looking at [softwaretestingfundamentals.com](http://softwaretestingfundamentals.com)." +msgstr "" + +#: testing/testing.md:665 +msgid "" +msgstr "" + +#: testing/testing.md:666 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: testing/testing.md:668 +# unordered list +msgid "- **Acceptance test:** A test that the program meets the project's fundamental requirements." +msgstr "" + +#: testing/testing.md:670 +# unordered list +msgid "- **Code coverage:** A measure which describes how much of the source code is exercised by the test suite." +msgstr "" + +#: testing/testing.md:672 +# unordered list +msgid "- **End to end test:** A test that runs the program from beginning to end and verifies that the output is correct." +msgstr "" + +#: testing/testing.md:674 +# unordered list +msgid "- **Integration test:** A test where units of code are combined and run, and the output is verified to check the units have been correctly integrated." +msgstr "" + +#: testing/testing.md:676 +# unordered list +msgid "- **Mocking:** Replace a real object with a pretend one to use when running tests." +msgstr "" + +#: testing/testing.md:678 +# unordered list +msgid "- **Regression test:** Comparing the result of a test before and after the code has been altered. If the output has changed a problem has been introduced somewhere in the program, and an error is thrown." +msgstr "" + +#: testing/testing.md:680 +# unordered list +msgid "- **Runtime test:** Tests embedded within the program which are run as part of it." +msgstr "" + +#: testing/testing.md:682 +# unordered list +msgid "- **Smoke test:** Very brief initial checks that ensure the basic requirements needed to run the project hold." +msgstr "" + +#: testing/testing.md:684 +# unordered list +msgid "- **Stochastic code:** Code which, while correct, does not always output the same result. For example a program that outputs ten random numbers will generate a different result each time, despite being correct." +msgstr "" + +#: testing/testing.md:686 +# unordered list +msgid "- **System test:** See \"end to end test\"." +msgstr "" + +#: testing/testing.md:688 +# unordered list +msgid "- **Test driven development:** A process of code development where unit tests are written before the units themselves." +msgstr "" + +#: testing/testing.md:690 +# unordered list +msgid "- **Test stub:** Fake implementations of parts of code which are used in testing to remove dependences." +msgstr "" + +#: testing/testing.md:692 +# unordered list +msgid "- **Test suite:** The tests that have been written for a project." +msgstr "" + +#: testing/testing.md:694 +# unordered list +msgid "- **Testing framework:** Tools that make writing and running tests less labour intensive." +msgstr "" + +#: testing/testing.md:696 +# unordered list +msgid "- **Unit:** A small piece of code that does one simple thing. It usually has one or a few inputs and usually a single output." +msgstr "" + +#: testing/testing.md:698 +# unordered list +msgid "- **Unit test:** A test that checks the behaviour of a unit." +msgstr "" + +#: testing/testing.md:700 +msgid "" +msgstr "" + +#: testing/testing.md:701 +# header +msgid "## Bibliography" +msgstr "" + +#: testing/testing.md:703 +# header +msgid "### Materials used: How this will help you/ why this is useful" +msgstr "" + +#: testing/testing.md:705 +#: testing/testing.md:751 +# unordered list +msgid "- [Talk by Chrys Woods](https://drive.google.com/file/d/1CBTAhCVixccui1DjeUT13qh6ga5SDXjl/view) [**Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License**](https://chryswoods.com/main/copyright.html)" +msgstr "" + +#: testing/testing.md:706 +# unordered list +msgid "- [Turing testing course basics](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/01testingbasics.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:707 +# unordered list +msgid "- [SSI blog](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:709 +# header +msgid "### Materials used: General guidance and good practice for testing" +msgstr "" + +#: testing/testing.md:711 +# unordered list +msgid "- [SSI blog on testing software](https://www.software.ac.uk/resources/guides/testing-your-software?_ga=2.39233514.830272891.1552653652-1336468516.1531506806) **Creative Commons Attribution Non-Commercial 2.5 License.**" +msgstr "" + +#: testing/testing.md:712 +# unordered list +msgid "- [Turing testing course](https://alan-turing-institute.github.io/rsd-engineeringcourse/ch03tests/03pytest.html) **Creative Commons share and remix**" +msgstr "" + +#: testing/testing.md:713 +# unordered list +msgid "- [Mocking](https://www.vogella.com/tutorials/Mockito/article.html) **Attribution-NonCommercial-ShareAlike 3.0 Germany (CC BY-NC-SA 3.0 DE)**" +msgstr "" + +#: testing/testing.md:714 +# unordered list +msgid "- [Testing with floating points](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:716 +# header +msgid "### Materials used: Types of tests" +msgstr "" + +#: testing/testing.md:718 +# unordered list +msgid "- [Software testing fundamentals: levels of tests](http://softwaretestingfundamentals.com/software-testing-levels/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:720 +# header +msgid "### Materials used: Smoke testing" +msgstr "" + +#: testing/testing.md:722 +# unordered list +msgid "- [Digitalocean](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:724 +# header +msgid "### Materials used: Unit testing" +msgstr "" + +#: testing/testing.md:726 +#: testing/testing.md:731 +#: testing/testing.md:737 +#: testing/testing.md:740 +# unordered list +msgid "- [An introduction to continuous integration](https://www.digitalocean.com/community/tutorials/an-introduction-to-continuous-integration-delivery-and-deployment) **Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.**" +msgstr "" + +#: testing/testing.md:727 +# unordered list +msgid "- [Software testing fundamentals: unit tests](http://softwaretestingfundamentals.com/unit-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:729 +# header +msgid "### Materials used: Integration testing" +msgstr "" + +#: testing/testing.md:732 +# unordered list +msgid "- [Software testing fundamentals: integration testing](http://softwaretestingfundamentals.com/integration-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:734 +# header +msgid "### Materials used: System testing" +msgstr "" + +#: testing/testing.md:736 +# unordered list +msgid "- [Software testing fundamentals: system testing](http://softwaretestingfundamentals.com/system-testing/) **Copyleft - 2019 STF**" +msgstr "" + +#: testing/testing.md:739 +# header +msgid "### Materials used: Acceptance testing" +msgstr "" + +#: testing/testing.md:742 +# header +msgid "### Materials used: Regression testing" +msgstr "" + +#: testing/testing.md:744 +# unordered list +msgid "- [Sound software](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License**" +msgstr "" + +#: testing/testing.md:745 +# unordered list +msgid "- [Software testing fundamentalsL regression testing](http://softwaretestingfundamentals.com/regression-testing/) **Copyleft**" +msgstr "" + +#: testing/testing.md:746 +# unordered list +msgid "- [Examples of Regression Testing by Cem Karner](http://www.testingeducation.org/k04/RegressionExamples.htm) **Creative Commons Attribution-ShareAlike License 2.0**" +msgstr "" + +#: testing/testing.md:747 +# unordered list +msgid "- [Adopting automated testing](https://github.com/softwaresaved/automated_testing/blob/master/README.md) **Apache License 2.0**" +msgstr "" + +#: testing/testing.md:749 +# header +msgid "### Materials used: Runtime testing" +msgstr "" + +#: testing/testing.md:753 +# header +msgid "### Materials used: Test driven development" +msgstr "" + +#: testing/testing.md:755 +# unordered list +msgid "- [Testing your software](https://software.ac.uk/resources/guides/testing-your-software) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:756 +# unordered list +msgid "- [Why bother](http://soundsoftware.ac.uk/unit-testing-why-bother/) **Creative Commons Attribution-NonCommercial 3.0 License.**" +msgstr "" + +#: testing/testing.md:758 +# header +msgid "### Materials used: glossary" +msgstr "" + +#: testing/testing.md:760 +# unordered list +msgid "- [Netherlands eScience centre](https://guide.esciencecenter.nl/best_practices/testing.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + diff --git a/book/content/po/toc.yml b/book/content/po/toc.yml new file mode 100644 index 00000000000..46b14b372f9 --- /dev/null +++ b/book/content/po/toc.yml @@ -0,0 +1,122 @@ +# Each entry has the following schema: +# +# - title: mytitle # Title of chapter or section +# url: /myurl # URL of section relative to the /content/ folder. +# sections: # Contains a list of more entries that make up the chapter's sections +# not_numbered: true # if the section shouldn't have a number in the sidebar +# expand_sections: true # if you'd like the sections of this chapter to always +# be expanded in the sidebar. +# external: true # Whether the URL is an external link or points to content in the book +# +# Below are some special values that trigger specific behavior: +# - search: true # Will provide a link to a search page +# - divider: true # Will insert a divider in the sidebar +# - header: My Header # Will insert a header with no link in the sidebar +# +# ============================== +# AUTOMATICALLY GENERATED TOC FILE. +# You should review the contents of this file, re-order items as you wish, +# and nest chapters in sections if you wish. The ======= symbols represent +# folder breaks. +# +# See the demo `toc.yml` for the right structure to follow. You can +# generate a demo book by running `jupyter-book create mybook --demo` +# ============================== + + + +# ===== NEW SECTION ======================================== +- title: Introduction + url: introduction/introduction +- title: Reproducibility + url: reproducibility/reproducibility + sections: + - title: Why reproducibility is important + url: reproducibility/01/importantforscience + - title: Why you should care + url: reproducibility/02/whycare + - title: Definitions + url: reproducibility/03/definitions + - title: Resources + url: reproducibility/04/resources +- title: Open Research + url: open_research/open_research + sections: + - title: Open data + url: open_research/01/opendata + - title: Open source software + url: open_research/02/opensourcesoftware + - title: Open hardware + url: open_research/03/openhardware + - title: Open access + url: open_research/04/openaccess + - title: Open notebooks + url: open_research/05/opennotebooks + - title: Open scholarship + url: open_research/06/openscholarship + - title: Resources + url: open_research/07/resources +- title: Version Control + url: version_control/version_control +- title: Collaborating on GitHub/GitLab + url: collaborating_github/collaborating_github + sections: + - title: README and Project Communication + url: collaborating_github/1/readme_communication + - title: Roadmapping + url: collaborating_github/2/roadmapping + - title: Getting Contributors + url: collaborating_github/3/getting_contributors + - title: Checklist and Bibliography + url: collaborating_github/4/checklist_bibliography +- title: Credit for reproducible research + url: credit/credit +- title: Research Data Management + url: rdm/rdm +- title: Reproducible Environments + url: reproducible_environments/reproducible_environments + sections: + - title: Choosing a tool + url: reproducible_environments/01/options + - title: Conda + url: reproducible_environments/02/package-management + - title: YAML + url: reproducible_environments/03/yaml + - title: Binder + url: reproducible_environments/04/binder + - title: Virtual machines + url: reproducible_environments/05/virtual-machines + - title: Containers + url: reproducible_environments/06/containers + - title: Checklist + url: reproducible_environments/07/checklist + - title: Resources + url: reproducible_environments/08/resources +- title: Testing + url: testing/testing +- title: Reviewing + url: reviewing/reviewing + sections: + - title: How this will help you and why this is useful + url: reviewing/01/how_helpful + - title: Best Practice + url: reviewing/02/best_practice + - title: Typical Workflows + url: reviewing/03/typical_workflows + - title: Checklists, what to learn next and bibliography + url: reviewing/04/checklists_bib +- title: Continuous Integration + url: continuous_integration/continuous_integration +- title: Reproducible Research with Make + url: make/make +- title: Risk Assessment + url: risk_assessment/risk_assessment + sections: + - title: Long Read on Risk Assessment + url: risk_assessment/01/longreadriskassessment + - title: Summary + url: risk_assessment/02/finalsummary +- title: BinderHub + url: binderhub/binderhub +- title: Glossary + url: glossary/glossary diff --git a/book/content/po/version_control.es.po b/book/content/po/version_control.es.po new file mode 100644 index 00000000000..ee8e82785ec --- /dev/null +++ b/book/content/po/version_control.es.po @@ -0,0 +1,2072 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Place Holder , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:03+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Place Holder \n" +"Language-Team: Spanish \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: version_control/version_control.md:93 +#: version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: version_control/version_control.md:142 +#: version_control/version_control.md:183 +#: version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: version_control/version_control.md:150 +#: version_control/version_control.md:235 +#: version_control/version_control.md:301 +#: version_control/version_control.md:343 +#: version_control/version_control.md:406 +#: version_control/version_control.md:447 +#: version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: version_control/version_control.md:155 +#: version_control/version_control.md:241 +#: version_control/version_control.md:305 +#: version_control/version_control.md:352 +#: version_control/version_control.md:410 +#: version_control/version_control.md:473 +#: version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: version_control/version_control.md:160 +#: version_control/version_control.md:251 +#: version_control/version_control.md:313 +#: version_control/version_control.md:370 +#: version_control/version_control.md:415 +#: version_control/version_control.md:493 +#: version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: version_control/version_control.md:216 +#: version_control/version_control.md:266 +#: version_control/version_control.md:334 +#: version_control/version_control.md:396 +#: version_control/version_control.md:438 +#: version_control/version_control.md:513 +#: version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: version_control/version_control.md:578 +#: version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/version_control.pot b/book/content/po/version_control.pot new file mode 100644 index 00000000000..93cb25a34f1 --- /dev/null +++ b/book/content/po/version_control.pot @@ -0,0 +1,2072 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: version_control/version_control.md:93 +#: version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: version_control/version_control.md:142 +#: version_control/version_control.md:183 +#: version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: version_control/version_control.md:150 +#: version_control/version_control.md:235 +#: version_control/version_control.md:301 +#: version_control/version_control.md:343 +#: version_control/version_control.md:406 +#: version_control/version_control.md:447 +#: version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: version_control/version_control.md:155 +#: version_control/version_control.md:241 +#: version_control/version_control.md:305 +#: version_control/version_control.md:352 +#: version_control/version_control.md:410 +#: version_control/version_control.md:473 +#: version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: version_control/version_control.md:160 +#: version_control/version_control.md:251 +#: version_control/version_control.md:313 +#: version_control/version_control.md:370 +#: version_control/version_control.md:415 +#: version_control/version_control.md:493 +#: version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: version_control/version_control.md:216 +#: version_control/version_control.md:266 +#: version_control/version_control.md:334 +#: version_control/version_control.md:396 +#: version_control/version_control.md:438 +#: version_control/version_control.md:513 +#: version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: version_control/version_control.md:578 +#: version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/version_control.tr.po b/book/content/po/version_control.tr.po new file mode 100644 index 00000000000..93cb25a34f1 --- /dev/null +++ b/book/content/po/version_control.tr.po @@ -0,0 +1,2072 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# FIRST AUTHOR , YEAR. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 19:08:04+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME \n" +"Language-Team: LANGUAGE \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: version_control/version_control.md:93 +#: version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: version_control/version_control.md:142 +#: version_control/version_control.md:183 +#: version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: version_control/version_control.md:150 +#: version_control/version_control.md:235 +#: version_control/version_control.md:301 +#: version_control/version_control.md:343 +#: version_control/version_control.md:406 +#: version_control/version_control.md:447 +#: version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: version_control/version_control.md:155 +#: version_control/version_control.md:241 +#: version_control/version_control.md:305 +#: version_control/version_control.md:352 +#: version_control/version_control.md:410 +#: version_control/version_control.md:473 +#: version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: version_control/version_control.md:160 +#: version_control/version_control.md:251 +#: version_control/version_control.md:313 +#: version_control/version_control.md:370 +#: version_control/version_control.md:415 +#: version_control/version_control.md:493 +#: version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: version_control/version_control.md:216 +#: version_control/version_control.md:266 +#: version_control/version_control.md:334 +#: version_control/version_control.md:396 +#: version_control/version_control.md:438 +#: version_control/version_control.md:513 +#: version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: version_control/version_control.md:578 +#: version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/content/po/version_control.zh_CN.po b/book/content/po/version_control.zh_CN.po new file mode 100644 index 00000000000..f83c6e05d95 --- /dev/null +++ b/book/content/po/version_control.zh_CN.po @@ -0,0 +1,2073 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER +# This file is distributed under the same license as the PACKAGE package. +# Tony Yang , 2020. +# +msgid "" +msgstr "" +"Project-Id-Version: content\n" +"Report-Msgid-Bugs-To: https://github.com/haiwen/seafile-docs/issues\n" +"POT-Creation-Date: 2020-02-05 14:52:59+0000\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: Tony Yang \n" +"Language-Team: zh_CN \n" +"Language: \n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" + +#: version_control/version_control.md:1 +# header +msgid "# Version Control" +msgstr "" + +#: version_control/version_control.md:3 +# header +msgid "## Prerequisites / recommended skill level" +msgstr "" + +#: version_control/version_control.md:5 +msgid "| Prerequisite | Importance | Notes |" +msgstr "" + +#: version_control/version_control.md:6 +msgid "| -------------|----------|------|" +msgstr "" + +#: version_control/version_control.md:7 +msgid "|[Experience with the command line](https://programminghistorian.org/en/lessons/intro-to-bash) | Helpful | It is possible to use version control through desktop and web browser based tools. These are discussed towards the end of this chapter, but the general principles and best practice discussed in the preceding sections are relevant regardless of whether the command line or a GUI is used. |" +msgstr "" + +#: version_control/version_control.md:9 +msgid "Recommended skill level: beginner - intermediate. Version control has a great deal of useful features, but total mastery is not necessary to achieve a great deal with it." +msgstr "" + +#: version_control/version_control.md:10 +msgid "Even a beginner utilising a few of the simplest features well can save themselves a great deal of time and drastically improve the reproducibility of their work." +msgstr "" + +#: version_control/version_control.md:11 +msgid "Naturally, we encourage readers to make use of the entire chapter, but readers should not be discouraged from using some tools they feel comfortable with if they are not comfortable with *all* the tools available." +msgstr "" + +#: version_control/version_control.md:13 +# header +msgid "## Summary" +msgstr "" + +#: version_control/version_control.md:15 +msgid "Version control keeps track of different versions of a project and allows past versions to be accessed easily." +msgstr "" + +#: version_control/version_control.md:16 +msgid "It also allows different versions of a project to be merged with minimal input from the user. " +msgstr "" + +#: version_control/version_control.md:17 +msgid "Version control is often associated with writing code, but it can also be used with writing projects." +msgstr "" + +#: version_control/version_control.md:18 +msgid "For example, if you are writing a paper with collaborators then version control is really important in helping you to see who has changed what. " +msgstr "" + +#: version_control/version_control.md:19 +msgid "Version control is used to some extent within many different programs, including ones you are likely to already be familiar with such as Word or Wordpress." +msgstr "" + +#: version_control/version_control.md:20 +msgid "There are numerous tools available for version control such as [Mercurial](https://www.mercurial-scm.org/) and [SVN](https://subversion.apache.org/). " +msgstr "" + +#: version_control/version_control.md:21 +msgid "The best know one is Git (and its web-based version, [GitHub](https://github.com/), which aids collaboration between researchers) which the instructions given in this chapter will be geared towards." +msgstr "" + +#: version_control/version_control.md:22 +msgid "There are a large number of detailed tutorials available online discussing the features and mechanics of how to use such systems (see the \"[Further reading](#further-reading)\" section at the end of the chapter)." +msgstr "" + +#: version_control/version_control.md:23 +msgid "This chapter aims to cover the general principles underpinning all version control systems, and best practice which applies for using all such systems." +msgstr "" + +#: version_control/version_control.md:25 +# header +msgid "## How version control is helpful" +msgstr "" + +#: version_control/version_control.md:27 +msgid "Researchers often have a large array of files (code, data, figures, notes) that they update but that they want to keep past versions of for reference." +msgstr "" + +#: version_control/version_control.md:28 +msgid "This process is often informal and haphazard, where multiple revisions of papers, code, and datasets are saved as duplicate copies with uninformative file names (for example, my_code.py my_code_2.py my_code_2a.py, my_code_2b.py)." +msgstr "" + +#: version_control/version_control.md:29 +msgid "As authors receive new data and feedback from peers and collaborators, maintaining those versions and merging changes can result in an unmanageable proliferation of files." +msgstr "" + +#: version_control/version_control.md:30 +msgid "It is also incredibly error prone." +msgstr "" + +#: version_control/version_control.md:31 +msgid "It is easy to forget what different files contain, or to copy over files you do not mean to." +msgstr "" + +#: version_control/version_control.md:32 +msgid "This leads to a great deal of time wasted on figuring out what files contain and reproducing accidently overwritten files." +msgstr "" + +#: version_control/version_control.md:34 +msgid "One solution to these problems would be to use a formal Version Control System (VCS)." +msgstr "" + +#: version_control/version_control.md:35 +msgid "A formal version is often a better solution than the lightweight version control that is often provided by text editing software packages." +msgstr "" + +#: version_control/version_control.md:36 +msgid "These systems have long been used in the software industry to manage code." +msgstr "" + +#: version_control/version_control.md:37 +msgid "Version control allows you to revert files you select back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified a file, find where and when a bug was introduced, and more. Using a version control system also generally means that if you screw things up or lose files, you can easily recover." +msgstr "" + +#: version_control/version_control.md:38 +msgid "In addition, you get all of this for very little overhead." +msgstr "" + +#: version_control/version_control.md:39 +msgid "Many people have felt the horror of losing days if not weeks of work when changes to a code break it irretrievably and can not be unpicked, and with this lies the key reasons to use version control: **it removes risk and saves time.**" +msgstr "" + +#: version_control/version_control.md:41 +msgid "Keeping past versions of a project stored and accessible makes it possible to track its entire evolution, making the outputs far more reproducible." +msgstr "" + +#: version_control/version_control.md:42 +msgid "Version control software does this in a neat and powerful way, and it often saves researchers a great deal of time on reproducing lost code or analysis." +msgstr "" + +#: version_control/version_control.md:43 +msgid "Further, version control gives researchers more freedom to try things out and experiment." +msgstr "" + +#: version_control/version_control.md:44 +msgid "It does this by eliminating the risk of subsequent changes irrevocably 'breaking' the code as previous working versions will remain accessible regardless of how complex or how many changes are made." +msgstr "" + +#: version_control/version_control.md:46 +msgid "Another benefit of version control is that it makes collaboration easier, safer, and allows what changes have been made, when, why, and by who to be tracked." +msgstr "" + +#: version_control/version_control.md:47 +msgid "It does this by allowing different versions of a project (either two versions written by the same person, or versions from many people) to be worked on separately." +msgstr "" + +#: version_control/version_control.md:48 +msgid "It also has facilities to automatically compare and combine versions of a project, tasks which are often both fiddly and time-consuming when done manually." +msgstr "" + +#: version_control/version_control.md:50 +# header +msgid "## Version control: What it is and how it can be used to manage an evolving project" +msgstr "" + +#: version_control/version_control.md:52 +# header +msgid "### What it is" +msgstr "" + +#: version_control/version_control.md:54 +msgid "What is \"version control\" and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later." +msgstr "" + +#: version_control/version_control.md:55 +msgid "It is typically applied to managing changes in code, though in reality you can do this with nearly any type of file on a computer." +msgstr "" + +#: version_control/version_control.md:57 +# header +msgid "### The basic workflow" +msgstr "" + +#: version_control/version_control.md:59 +msgid "The typical procedure for using version control is as follows:" +msgstr "" + +#: version_control/version_control.md:61 +# ordered list +msgid "1. Create some files - these may be text or code." +msgstr "" + +#: version_control/version_control.md:62 +# ordered list +msgid "2. Work on these files, changing, deleting or adding new content." +msgstr "" + +#: version_control/version_control.md:63 +# ordered list +msgid "3. Create a snapshot of the work at this time." +msgstr "" + +#: version_control/version_control.md:64 +msgid "This will be described differently in different software." +msgstr "" + +#: version_control/version_control.md:65 +msgid "Git will ask you to make a commit, other systems make ask you to make a timepoint or checkpoint or just to save your work." +msgstr "" + +#: version_control/version_control.md:67 +msgid "Keep doing work and making more and more snapshots." +msgstr "" + +#: version_control/version_control.md:68 +msgid "You can think of these as savepoints - if you need to go back to any point in time because of a mistake, or changing your mind about a decision, you can go back to get a file as it was then, or just return your entire project to a past state." +msgstr "" + +#: version_control/version_control.md:69 +msgid "An illustration of this is shown in the figure below. " +msgstr "" + +#: version_control/version_control.md:71 +msgid "![master_branch](../figures/master_branch.png)" +msgstr "" + +#: version_control/version_control.md:73 +msgid "In lots of version control systems you will be able to add a comment explaining what changes have been made in this version." +msgstr "" + +#: version_control/version_control.md:74 +msgid "These comments should be as clear as possible and make it easy to understand which version is which." +msgstr "" + +#: version_control/version_control.md:75 +msgid "This ensures that it is easy to find what you are looking for when you need to go back to a past version." +msgstr "" + +#: version_control/version_control.md:76 +msgid "Your collaborators will thank you, but so will future versions of yourself." +msgstr "" + +#: version_control/version_control.md:78 +# header +msgid "### Other facilities offered by version control" +msgstr "" + +#: version_control/version_control.md:80 +msgid "So you have your project and you want to add something new or try something out." +msgstr "" + +#: version_control/version_control.md:81 +msgid "With some of the more advanced version control systems (for example Git) you can make a branch to do this work on." +msgstr "" + +#: version_control/version_control.md:82 +msgid "Any work you do on your branch will not be present on your main project (referred to as your master branch) so it remains nice and safe and you can continue to work on it." +msgstr "" + +#: version_control/version_control.md:83 +msgid "Once you are happy with your New Thing you can 'merge' your branch back into your master copy." +msgstr "" + +#: version_control/version_control.md:85 +msgid "![one_branch](../figures/one_branch.png)" +msgstr "" + +#: version_control/version_control.md:87 +msgid "You can have more than one branch off of your master copy, and if one of your branches ends up not working you can either abandon it or delete it without the master branch of your project ever being impacted." +msgstr "" + +#: version_control/version_control.md:89 +msgid "![two_branches](../figures/two_branches.png)" +msgstr "" + +#: version_control/version_control.md:91 +msgid "If you want you can even have branches off of branches (and branches off of those branches and so on)." +msgstr "" + +#: version_control/version_control.md:93 +#: version_control/version_control.md:368 +msgid "![sub_branch](../figures/sub_branch.png)" +msgstr "" + +#: version_control/version_control.md:95 +msgid "No matter how many branches you have you can access past savepoints you made on any of them." +msgstr "" + +#: version_control/version_control.md:97 +# header +msgid "## Why should you use version control?" +msgstr "" + +#: version_control/version_control.md:99 +msgid "Version control can help you understand what changes you made in the past or why you did a certain analysis in the way you did it even weeks or months later when you have long since forgotten." +msgstr "" + +#: version_control/version_control.md:100 +msgid "By including comments and commit messages, each version can explain what changes it makes and what the version of the project it contains does." +msgstr "" + +#: version_control/version_control.md:101 +msgid "Commit messages also help others working on the same project to more easily understand what you did." +msgstr "" + +#: version_control/version_control.md:102 +msgid "This is helpful should you want to share your analysis (not only your data), and/or make it auditable -- more generally, **reproducible**, which is good scientific practice." +msgstr "" + +#: version_control/version_control.md:104 +msgid "A version control system stores all your changes neatly away so while it is still easy to access them your working directory is not cluttered by the debris of versions past that it is necessary to keep just in case." +msgstr "" + +#: version_control/version_control.md:105 +msgid "Similarly with version control there is no need to leave chunks of code commented should you ever need to come back to an old version again." +msgstr "" + +#: version_control/version_control.md:107 +msgid "Finally version control is invaluable for collaborative projects where different people work on the same code simultaneously." +msgstr "" + +#: version_control/version_control.md:108 +msgid "It allows the changes made by different people to be tracked, and can automatically combine people's work via merging saving a great deal of painstaking effort to do so manually." +msgstr "" + +#: version_control/version_control.md:109 +msgid "Moreover, version control hosting websites, such as GitHub, provide way to communicate in a more structured way, such as in code reviews, about commits and about issues." +msgstr "" + +#: version_control/version_control.md:111 +# header +msgid "## Getting Started" +msgstr "" + +#: version_control/version_control.md:113 +msgid "This is important to know, but it is not that exciting." +msgstr "" + +#: version_control/version_control.md:114 +msgid "Instructions for installing Git on linux, windows and mac machines are available [here](https://Git-scm.com/book/en/v2/Getting-Started-Installing-Git)." +msgstr "" + +#: version_control/version_control.md:115 +msgid "Once installation is complete, to start using version control for your project you just go into the directory that contains all of your files (subdirectories will be included) and run:" +msgstr "" + +#: version_control/version_control.md:117 +# code block +msgid "```\n" +"git init\n" +"```" +msgstr "" + +#: version_control/version_control.md:121 +msgid "in the terminal to create the Git repository (often called \"repo\" for short)." +msgstr "" + +#: version_control/version_control.md:122 +msgid "This only needs to be done once per project." +msgstr "" + +#: version_control/version_control.md:124 +msgid "Think of the repository as a place where the history is being stored." +msgstr "" + +#: version_control/version_control.md:125 +msgid "Each file in your working directory can be in one of two states: tracked or untracked by your repository." +msgstr "" + +#: version_control/version_control.md:126 +msgid "In short, tracked files are files that Git knows about." +msgstr "" + +#: version_control/version_control.md:127 +msgid "Untracked files are everything else — any files in your working directory that were not in your last snapshot." +msgstr "" + +#: version_control/version_control.md:128 +msgid "When you first initialise a repository with `git init` all of your files will be untracked because your repository it does not *have* a previous snapshot yet, so it doesn't know about any of your files." +msgstr "" + +#: version_control/version_control.md:129 +msgid "Therefore your next step is to add your files to the repository using:" +msgstr "" + +#: version_control/version_control.md:131 +# code block +msgid "```\n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:135 +msgid "This puts your changes into what is called the \"staging area\"." +msgstr "" + +#: version_control/version_control.md:136 +msgid "When you next commit any changes stored in your staging area will be recorded in your repository." +msgstr "" + +#: version_control/version_control.md:138 +msgid "![change_stage_repo](../figures/change_stage_repo.png)" +msgstr "" + +#: version_control/version_control.md:140 +msgid "The full stop after `git add` above adds all changes to your staging area. So now all your files are staged commit them using:" +msgstr "" + +#: version_control/version_control.md:142 +#: version_control/version_control.md:183 +#: version_control/version_control.md:255 +# code block +msgid "```\n" +"git commit\n" +"```" +msgstr "" + +#: version_control/version_control.md:146 +msgid "We will talk in more detail about these commands [later](#commits), but for now just know if you run them then congratulations, you have finished setting up you repository!" +msgstr "" + +#: version_control/version_control.md:148 +# header +msgid "## Commits" +msgstr "" + +#: version_control/version_control.md:150 +#: version_control/version_control.md:235 +#: version_control/version_control.md:301 +#: version_control/version_control.md:343 +#: version_control/version_control.md:406 +#: version_control/version_control.md:447 +#: version_control/version_control.md:541 +# header +msgid "### The problem" +msgstr "" + +#: version_control/version_control.md:152 +msgid "When working on a project you will make numerous changes to your files as you progress. Sometimes you may need to undo changes, take another look at past versions, or compare versions." +msgstr "" + +#: version_control/version_control.md:153 +msgid "Saving each version individually (such as `version_1.py` and `version_2.py`) is messy and quickly becomes impractical." +msgstr "" + +#: version_control/version_control.md:155 +#: version_control/version_control.md:241 +#: version_control/version_control.md:305 +#: version_control/version_control.md:352 +#: version_control/version_control.md:410 +#: version_control/version_control.md:473 +#: version_control/version_control.md:546 +# header +msgid "### The solution" +msgstr "" + +#: version_control/version_control.md:157 +msgid "By making commits you can save versions of your code and switch between them/compare them easily without cluttering up your directory." +msgstr "" + +#: version_control/version_control.md:158 +msgid "Commits serve as checkpoints where individual files or an entire project can be safely reverted to when necessary." +msgstr "" + +#: version_control/version_control.md:160 +#: version_control/version_control.md:251 +#: version_control/version_control.md:313 +#: version_control/version_control.md:370 +#: version_control/version_control.md:415 +#: version_control/version_control.md:493 +#: version_control/version_control.md:561 +# header +msgid "### How to do it" +msgstr "" + +#: version_control/version_control.md:162 +msgid "When you have made a series of changes and you want to commit them you first add these changes to your staging area using `git add`." +msgstr "" + +#: version_control/version_control.md:163 +msgid "You can add all your changes using:" +msgstr "" + +#: version_control/version_control.md:165 +# code block +msgid "``` \n" +"git add .\n" +"```" +msgstr "" + +#: version_control/version_control.md:169 +msgid "or you can add the changes to specific files via:" +msgstr "" + +#: version_control/version_control.md:171 +# code block +msgid "``` \n" +"git add your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:175 +msgid "If you are ever unsure what files have been added, what files have been changed, what files are untracked, you can run the following to find out:" +msgstr "" + +#: version_control/version_control.md:177 +# code block +msgid "```\n" +"git status\n" +"```" +msgstr "" + +#: version_control/version_control.md:181 +msgid "When you're ready you can commit everything in your staging area by running" +msgstr "" + +#: version_control/version_control.md:187 +msgid "It's that easy." +msgstr "" + +#: version_control/version_control.md:189 +msgid "You can see a log of your previous commits using" +msgstr "" + +#: version_control/version_control.md:191 +# code block +msgid "```\n" +"git log\n" +"```" +msgstr "" + +#: version_control/version_control.md:195 +msgid "In this log you'll see that each commit is automatically tagged with a unique string of numbers and letters called a SHA which you can use to access and compare them." +msgstr "" + +#: version_control/version_control.md:197 +# header +msgid "#### Retrieving past versions" +msgstr "" + +#: version_control/version_control.md:199 +msgid "To cancel your latest commit run" +msgstr "" + +#: version_control/version_control.md:200 +# code block +msgid "```\n" +"git revert HEAD\n" +"```" +msgstr "" + +#: version_control/version_control.md:204 +msgid "which automatically makes a new commit that undoes those changes. You may want to retrieve a version form weeks or months ago. To do this first use `git log` to find the SHA of the version you want to retrieve. To reset your entire project to this version do" +msgstr "" + +#: version_control/version_control.md:206 +# code block +msgid "```\n" +"git checkout SHA_of_the_version\n" +"```" +msgstr "" + +#: version_control/version_control.md:210 +msgid " You may just want the old version of a single file though, and not the previous version of the whole project. To retrieve this use" +msgstr "" + +#: version_control/version_control.md:212 +# code block +msgid " ```\n" +" git checkout SHA_of_the_version -- your_file_name\n" +" ```" +msgstr "" + +#: version_control/version_control.md:216 +#: version_control/version_control.md:266 +#: version_control/version_control.md:334 +#: version_control/version_control.md:396 +#: version_control/version_control.md:438 +#: version_control/version_control.md:513 +#: version_control/version_control.md:627 +# header +msgid "### Good practice" +msgstr "" + +#: version_control/version_control.md:218 +msgid "Commits should be 'atomic'. That is, **they should do one simple thing and they should do it completely**. For example, adding a new function or renaming a variable. If a lot of different changes to your project are all committed together then if something goes wrong it can be hard to unpick what in this set of changes if causing the problem, and undoing the whole commit may throw away valid and useful work along with the bug. That said **you do not necessarily need to do per-file commits**. For example if I add a figure to this chapter here, let's choose something to catch the attention of someone skimming through:" +msgstr "" + +#: version_control/version_control.md:220 +msgid "![flipped_taj_mahal](../figures/flipped_taj_mahal.png)" +msgstr "" + +#: version_control/version_control.md:222 +msgid "then when I do this two files are changed:" +msgstr "" + +#: version_control/version_control.md:224 +# ordered list +msgid "1. The figure file has been added." +msgstr "" + +#: version_control/version_control.md:225 +# ordered list +msgid "2. I have added a reference to this figure in the chapter so it will be displayed." +msgstr "" + +#: version_control/version_control.md:227 +msgid "So two files are affected, but \"Add figure to version control chapter\" is a single, *atomic* unit of work, so only one commit is necessary." +msgstr "" + +#: version_control/version_control.md:229 +msgid "To aid in making atomic commits it is good practice to **specify the files to be committed**, that is, adding files to the staging area by name (`git add your_file_name`) rather than adding everything (`git add .`). This prevents you from unintentionally bundling different changes together, for example if you have made a change to file A while primarily working on file B you may have forgotten this when you go to commit, and with `git add .` file A would be brought along for the ride." +msgstr "" + +#: version_control/version_control.md:231 +msgid "Finally, **do not commit anything that can be regenerated from other things that were committed unless it is something that would take hours to regenerate**. Generated files just clutter up your repository and may contain features such as timestamps that can cause annoying merge conflicts (see [below](#merge-conflicts)). On a similar note you should not commit configuration files, specifically configuration files that might change from environment to environment. You can instruct Git to ignore certain files by creating a file called `.Gitignore` and including their names in it." +msgstr "" + +#: version_control/version_control.md:233 +# header +msgid "## Commit messages" +msgstr "" + +#: version_control/version_control.md:237 +msgid "As you work on you project you will make more and more commits." +msgstr "" + +#: version_control/version_control.md:238 +msgid "Without any other information it can be hard to remember which version of your project is in which." +msgstr "" + +#: version_control/version_control.md:239 +msgid "Storing past versions is useless if you can not understand them, and figuring out what they contain by inspecting the code is frustrating and takes valuable time. " +msgstr "" + +#: version_control/version_control.md:243 +msgid "When you commit you have the chance to write a commit message describing what the commit is and what it does, and you should always, *always,* **_always_** do so." +msgstr "" + +#: version_control/version_control.md:244 +msgid "A commit message gets attached to the commit so if you look back at it (for example, via `git log`) it will show up." +msgstr "" + +#: version_control/version_control.md:245 +msgid "Creating insightful and descriptive commit messages is one of the best things you can do to get the most out of version control." +msgstr "" + +#: version_control/version_control.md:246 +msgid "It lets people (and your future self when you have long since forgotten what you were doing and why) quickly understand what changes a commit contains without having to carefully read code and waste time figuring it out." +msgstr "" + +#: version_control/version_control.md:247 +msgid "Good commit messages improve your code quality by drastically reducing its WTF/min ratio:" +msgstr "" + +#: version_control/version_control.md:249 +msgid "![wtf_per_min](../figures/wtf_per_min.jpg)" +msgstr "" + +#: version_control/version_control.md:253 +msgid "When you commit via:" +msgstr "" + +#: version_control/version_control.md:259 +msgid "notice that a field appears (either within the terminal or in a text editor) where a commit message can be written. Simply do so and save (and close if writing the message via text editor)." +msgstr "" + +#: version_control/version_control.md:260 +msgid "To set your preferred editor as the default do:" +msgstr "" + +#: version_control/version_control.md:262 +# code block +msgid "```\n" +"git config --global core.editor \"your_preferred_editor\"\n" +"```" +msgstr "" + +#: version_control/version_control.md:268 +msgid "The number one rule is: **make it meaningful**." +msgstr "" + +#: version_control/version_control.md:269 +msgid "A commit message like \"Fixed a bug\" leaves it entirely up to the person looking at the commit (again, this person may very well be you a few months in the future when you have forgotten what you were doing) to waste time figuring out what the bug was, what changes you actually made, and how they fixed it." +msgstr "" + +#: version_control/version_control.md:270 +msgid "As such a good commit message should **explain what you did, why you did it, and what is impacted by the change**." +msgstr "" + +#: version_control/version_control.md:271 +msgid "As with comments you should **describe what the code is doing rather than the code itself**. For example, it is not obvious what \"Change N_sim to 10\" actually does, but \"Change number of simulations run by the program to 10\" is clear." +msgstr "" + +#: version_control/version_control.md:273 +msgid "**Summarise the change** the commit contains in the first line (50-72 characters), then leave a blank line before you continue with the body of the message. By doing this when shortened versions of `git log` are used just the summary will appear. This makes it much easier to quickly search through a large number of commits." +msgstr "" + +#: version_control/version_control.md:274 +msgid "It is also a good practice to **use the imperative present tense** in these messages. In other words, use commands." +msgstr "" + +#: version_control/version_control.md:275 +msgid "Instead of \"I added tests for\" or \"Adding tests for\", use \"Add tests for\"." +msgstr "" + +#: version_control/version_control.md:277 +msgid "Here is a good example of commit message structure:" +msgstr "" + +#: version_control/version_control.md:279 +# code block +msgid "```\n" +"Short (50 chars or less) summary of changes\n" +"\n" +"More detailed explanatory text, if necessary. Wrap it to\n" +"about 72 characters or so. In some contexts, the first\n" +"line is treated as the subject of an email and the rest of\n" +"the text as the body. The blank line separating the\n" +"summary from the body is critical (unless you omit the body\n" +"entirely); tools like rebase can get confused if you run\n" +"the two together.\n" +"\n" +"Further paragraphs come after blank lines.\n" +"\n" +" - Bullet points are okay, too\n" +"\n" +" - Typically a hyphen or asterisk is used for the bullet,\n" +" preceded by a single space, with blank lines in\n" +" between, but conventions vary here\n" +"```" +msgstr "" + +#: version_control/version_control.md:299 +# header +msgid "## Comparing versions" +msgstr "" + +#: version_control/version_control.md:303 +msgid "At some point it is likely you will need/want to compare versions of a project, for example to see what version was used to generate a certain result." +msgstr "" + +#: version_control/version_control.md:307 +msgid "In short: `git diff`." +msgstr "" + +#: version_control/version_control.md:309 +msgid "Diffing is a function that takes two input data sets and outputs the changes between them." +msgstr "" + +#: version_control/version_control.md:310 +msgid "`git diff` is a multi-use Git command that when executed runs a diff function on Git data sources." +msgstr "" + +#: version_control/version_control.md:311 +msgid "These data sources can be commits, branches, files and more." +msgstr "" + +#: version_control/version_control.md:315 +msgid "By default `git diff` will show you any uncommitted changes since the last commit." +msgstr "" + +#: version_control/version_control.md:316 +msgid "If you want to compare two specific things the syntax is:" +msgstr "" + +#: version_control/version_control.md:318 +# code block +msgid "```\n" +"git diff thing_a thing_b\n" +"```" +msgstr "" + +#: version_control/version_control.md:322 +msgid "For example if you want to compare how a file has changed between two commits use `git log` to get the SHAs of those commits and run:" +msgstr "" + +#: version_control/version_control.md:324 +# code block +msgid "```\n" +"git diff SHA_a:your_file_name SHA_b:your_file_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:328 +msgid "Or if you wanted to compare two branches it would be:" +msgstr "" + +#: version_control/version_control.md:330 +# code block +msgid "```\n" +"git diff branch_name other_branch_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:336 +msgid "**Use it**." +msgstr "" + +#: version_control/version_control.md:337 +msgid "With a little familiarity `git diff` becomes an extremely powerful tool you can use to track what files have changed and exactly what those changes are." +msgstr "" + +#: version_control/version_control.md:338 +msgid "This is extremely valuable for unpicking bugs and comparing work done by different people." +msgstr "" + +#: version_control/version_control.md:339 +msgid "Be careful to **understand what exactly is being compared** and where possible **only compare the relevant files** for what you are interested in to avoid large amounts of extraneous information." +msgstr "" + +#: version_control/version_control.md:341 +# header +msgid "## Branches" +msgstr "" + +#: version_control/version_control.md:345 +msgid "If you add a new feature to your project you run the risk of accidentally breaking your working code as you make changes to it." +msgstr "" + +#: version_control/version_control.md:346 +msgid "This would be very bad for active users of your project, even if the only active user is you." +msgstr "" + +#: version_control/version_control.md:347 +msgid "Also version control systems are regularly used for collaboration." +msgstr "" + +#: version_control/version_control.md:348 +msgid "If everyone starts programming on top of the master branch, it will cause a lot of confusion." +msgstr "" + +#: version_control/version_control.md:349 +msgid "Some people may write faulty/buggy code or simply the kind of code/feature others may not want in the project." +msgstr "" + +#: version_control/version_control.md:350 +msgid "There needs to be a way allow new work to be done on a project whilst protecting work that has already been done." +msgstr "" + +#: version_control/version_control.md:354 +msgid "Branches." +msgstr "" + +#: version_control/version_control.md:355 +msgid "At the start of this chapter an [overview](#other-facilities-offered-by-version-control) was given of the concept of branches, but let's recap." +msgstr "" + +#: version_control/version_control.md:356 +msgid "You have a project, and you make commits on it." +msgstr "" + +#: version_control/version_control.md:357 +msgid "By default you have one branch, called 'master'." +msgstr "" + +#: version_control/version_control.md:358 +msgid "Making a branch essentially makes a copy of your code which you can work on and continue to make commits to." +msgstr "" + +#: version_control/version_control.md:359 +msgid "Meanwhile your master branch is untouched by these changes, and you can continue to make commits on it too." +msgstr "" + +#: version_control/version_control.md:360 +msgid "Once you are happy with whatever you were working on on a branch you can merge it into your master branch (or indeed any other branch)." +msgstr "" + +#: version_control/version_control.md:361 +msgid "Merging will be covered in the [next section](#merging)." +msgstr "" + +#: version_control/version_control.md:362 +msgid "If your work on a branch does not work out you can delete or abandon it (for example, Feature B in the diagram below) rather than spending time unpicking your changes if you were doing all your work on the master copy." +msgstr "" + +#: version_control/version_control.md:363 +msgid "You can have as many branches off of branches as you desire (for example, Feature A-1)." +msgstr "" + +#: version_control/version_control.md:365 +msgid "Using branches keeps working code safe, particularly in collaborations." +msgstr "" + +#: version_control/version_control.md:366 +msgid "Each contibuter can have their own branch or branches which are only merged into the main project when they are ready." +msgstr "" + +#: version_control/version_control.md:372 +msgid "You can create a branch and switch to it using:" +msgstr "" + +#: version_control/version_control.md:373 +# code block +msgid "```\n" +"git checkout -b name_of_your_new_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:377 +msgid "To change between branches:" +msgstr "" + +#: version_control/version_control.md:378 +# code block +msgid "```\n" +"git checkout name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:382 +msgid "though you must commit any work you have in progress before you will be able to switch. You can see all branches of your project simply using:" +msgstr "" + +#: version_control/version_control.md:384 +# code block +msgid "```\n" +"git branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:387 +msgid "which will output a list with an asterix next to the branch you are on." +msgstr "" + +#: version_control/version_control.md:388 +msgid "You can also use `git status` if you have forgotten which branch you are on." +msgstr "" + +#: version_control/version_control.md:390 +msgid "If you decide to get rid of a branch you can delete it with:" +msgstr "" + +#: version_control/version_control.md:392 +# code block +msgid "```\n" +"git branch -D name_of_the_branch\n" +"```" +msgstr "" + +#: version_control/version_control.md:398 +msgid "Branches should be used to **keep the master branch clean**." +msgstr "" + +#: version_control/version_control.md:399 +msgid "That is, master should only contain work which is complete and tested and so rightfully belongs in the master version of the project." +msgstr "" + +#: version_control/version_control.md:400 +msgid "Similarly you should try to keep individual branches as clean as possible by **only adding one new feature per branch**, because if you are working on several features some may be finished and ready to merge into master while others are still under development." +msgstr "" + +#: version_control/version_control.md:401 +msgid "Keeping your branches clean means only making changes related to the feature on the feature's branch." +msgstr "" + +#: version_control/version_control.md:402 +msgid "Give your branches **sensible names**, \"new_feature\" is all well and good until you start developing a newer feature on another branch." +msgstr "" + +#: version_control/version_control.md:404 +# header +msgid "## Merging" +msgstr "" + +#: version_control/version_control.md:408 +msgid "Once you've finished up some work on a branch you need to integrate it to your main project (or any other branch)." +msgstr "" + +#: version_control/version_control.md:412 +msgid "Merge the branch with your work on into your target branch." +msgstr "" + +#: version_control/version_control.md:413 +msgid "You can also use merging to combine work that other people have done with your own and vice versa." +msgstr "" + +#: version_control/version_control.md:417 +msgid "To merge some branch, branch_A, into another branch, branch_B, switch to branch_A via `git checkout branch_A` and merge it into branch_B by:" +msgstr "" + +#: version_control/version_control.md:419 +# code block +msgid "```\n" +"git merge branch_B\n" +"```" +msgstr "" + +#: version_control/version_control.md:423 +msgid "Merging will not be possible if there are changes in either your working directory or staging area that could be written over by the files that you are merging in." +msgstr "" + +#: version_control/version_control.md:424 +msgid "If this happens, there are no merge conflicts in individual files." +msgstr "" + +#: version_control/version_control.md:425 +msgid "You need to commit or stash the files it lists and then try again." +msgstr "" + +#: version_control/version_control.md:426 +msgid "The error messages are as follows:" +msgstr "" + +#: version_control/version_control.md:428 +# code block +msgid "```\n" +"error: Entry 'your_file_name' not uptodate. Cannot merge. (Changes in working directory)\n" +"```" +msgstr "" + +#: version_control/version_control.md:432 +msgid "or" +msgstr "" + +#: version_control/version_control.md:434 +# code block +msgid "```\n" +"error: Entry 'your_file_name' would be overwritten by merge. Cannot merge. (Changes in staging area)\n" +"```" +msgstr "" + +#: version_control/version_control.md:440 +msgid "First and foremost your **master branch should always be stable**, only merge work that is finished and tested into it." +msgstr "" + +#: version_control/version_control.md:441 +msgid "If your project is collaborative then it is a good idea to **merge changes that others make into you own work frequently**." +msgstr "" + +#: version_control/version_control.md:442 +msgid "If you do not it is very easy for merge conflicts to arise (next section)." +msgstr "" + +#: version_control/version_control.md:443 +msgid "Similarly, share your own changes with your collaborators often." +msgstr "" + +#: version_control/version_control.md:445 +# header +msgid "## Merge conflicts" +msgstr "" + +#: version_control/version_control.md:449 +msgid "When changes to made to the same file on different branches sometimes those changes may be incompatible." +msgstr "" + +#: version_control/version_control.md:450 +msgid "This most commonly occurs in collaborative projects, but it happens in solo projects too." +msgstr "" + +#: version_control/version_control.md:451 +msgid "Let's say there's a project and it contains a file with this line of code:" +msgstr "" + +#: version_control/version_control.md:453 +# code block +msgid "```\n" +"print('hello world')\n" +"```" +msgstr "" + +#: version_control/version_control.md:457 +msgid "Lets say one person, on their branch, decides to pep it up a bit and changes this line to:" +msgstr "" + +#: version_control/version_control.md:459 +# code block +msgid "```\n" +"print('hello world!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:463 +msgid "while someone else on another branch instead decides to change `print('hello world')` to:" +msgstr "" + +#: version_control/version_control.md:465 +# code block +msgid "```\n" +"print('Hello World')\n" +"```" +msgstr "" + +#: version_control/version_control.md:469 +msgid "They continue doing work on their respective branches and eventually decide to merge." +msgstr "" + +#: version_control/version_control.md:470 +msgid "Their version control software then goes through and combines their changes into a single version of the file, *but* when it gets to the hello world statement it doesn't know which version to use." +msgstr "" + +#: version_control/version_control.md:471 +msgid "This is a merge conflict: incompatible changes have been made to the same file." +msgstr "" + +#: version_control/version_control.md:475 +msgid "When a merge conflict arises it will be flagged during the merge process." +msgstr "" + +#: version_control/version_control.md:476 +msgid "Within the files with conflicts the incompatible changes will be marked so you can fix them:" +msgstr "" + +#: version_control/version_control.md:478 +# code block +msgid "```\n" +"<<<<<<< HEAD\n" +"print('hello world!!!')\n" +"=======\n" +"print('Hello World')\n" +">>>>>>> master\n" +"```" +msgstr "" + +#: version_control/version_control.md:485 +msgid "`<<<<<<<`: Indicates the start of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:486 +msgid "The first set of lines are the lines from the file that you were trying to merge the changes into." +msgstr "" + +#: version_control/version_control.md:488 +msgid "`=======`: Indicates the break point used for comparison." +msgstr "" + +#: version_control/version_control.md:489 +msgid "Breaks up changes that user has committed (above) to changes coming from merge (below) to visually see the differences." +msgstr "" + +#: version_control/version_control.md:491 +msgid "`>>>>>>>`: Indicates the end of the lines that had a merge conflict." +msgstr "" + +#: version_control/version_control.md:495 +msgid "You resolve a conflict by editing the file to manually merge the parts of the file that Git had trouble merging." +msgstr "" + +#: version_control/version_control.md:496 +msgid "This may mean discarding either your changes or someone else's or doing a mix of the two." +msgstr "" + +#: version_control/version_control.md:497 +msgid "You will also need to delete the `<<<<<<<`, `=======`, and `>>>>>>>` in the file." +msgstr "" + +#: version_control/version_control.md:498 +msgid "So in this project the users may decide in favour of one `hello world` over another, or they may decide to replace the conflict with:" +msgstr "" + +#: version_control/version_control.md:500 +# code block +msgid "```\n" +"print('Hello World!!!')\n" +"```" +msgstr "" + +#: version_control/version_control.md:504 +msgid "Once you have fixed the conflicts commit the new version." +msgstr "" + +#: version_control/version_control.md:505 +msgid "You have now resolved the conflict." +msgstr "" + +#: version_control/version_control.md:506 +msgid "If, during the process, you need a reminder of which files the conflicts are in you can use `git status` to find out." +msgstr "" + +#: version_control/version_control.md:508 +msgid "If you find there are particularly nasty conflicts and you want to abort the merge you can using:" +msgstr "" + +#: version_control/version_control.md:509 +# code block +msgid "```\n" +"git merge --abort\n" +"```" +msgstr "" + +#: version_control/version_control.md:515 +msgid "Before you start trying to resolve conflicts **make sure you fully understand the changes and how they are incompatible**. If you do not you risk making things more tangled." +msgstr "" + +#: version_control/version_control.md:516 +msgid "Once you do and you go about fixing the problem **be careful, but do not be afraid**; the whole point of version control is your past versions are all safe." +msgstr "" + +#: version_control/version_control.md:517 +msgid "Nevertheless merge conflicts can be intimidating to resolve, especially if you are merging branches that diverged a great many commits ago which may now have many incompatibilities." +msgstr "" + +#: version_control/version_control.md:518 +msgid "This is why it is good practice to **merge other's changes into your work frequently**." +msgstr "" + +#: version_control/version_control.md:520 +msgid "There are **tools** available to assist in resolving merge conflicts, some are free, some are not." +msgstr "" + +#: version_control/version_control.md:521 +msgid "Find and familiarise yourself with one that works for you." +msgstr "" + +#: version_control/version_control.md:522 +msgid "Commonly used merge tools include [KDiff3](http://kdiff3.sourceforge.net/), [Beyond Compare](https://www.scootersoftware.com/), [Meld](http://meldmerge.org/), and [P4Merge](https://www.perforce.com/products/helix-core-apps/merge-diff-tool-p4merge)." +msgstr "" + +#: version_control/version_control.md:523 +msgid "To set a tool as your default do:" +msgstr "" + +#: version_control/version_control.md:525 +# code block +msgid "```\n" +"git config --global merge.tool name_of_the_tool\n" +"```" +msgstr "" + +#: version_control/version_control.md:529 +msgid "and launch it with:" +msgstr "" + +#: version_control/version_control.md:531 +# code block +msgid "```\n" +"git mergetool\n" +"```" +msgstr "" + +#: version_control/version_control.md:535 +msgid "Fundamentally the best way to deal with merge conflicts is to, so far as is possible, **ensure they do not happen in the first place**." +msgstr "" + +#: version_control/version_control.md:536 +msgid "You can improve your odds on this by **keeping branches clean and focused on a single issue, and involving as few files as possible**." +msgstr "" + +#: version_control/version_control.md:537 +msgid "Before merging make sure you know what's in both branches, and if you are not the only one that has worked on the branches then **keep the lines of communication open** so you are all aware of what the others are doing." +msgstr "" + +#: version_control/version_control.md:539 +# header +msgid "## GitHub" +msgstr "" + +#: version_control/version_control.md:543 +msgid "When multiple people work on the same project (which is becoming more and more common as research becomes increasingly collaborative) it becomes difficult to keep track of what changes have been made and by who." +msgstr "" + +#: version_control/version_control.md:544 +msgid "It is also often difficult and time-consuming to manually incorporate the different participant's work into a whole even if all of their changes are compatible. " +msgstr "" + +#: version_control/version_control.md:548 +msgid "Hosting the project on a distributed version control system such as GitHub." +msgstr "" + +#: version_control/version_control.md:549 +msgid "Collaborators can then clone the project and work on the cloned copy making commits and new branches without impacting the original repository." +msgstr "" + +#: version_control/version_control.md:550 +msgid "Collaborators can then *push* their work to each other, and *pull* other's work into their own copy." +msgstr "" + +#: version_control/version_control.md:551 +msgid "In this way it is easy to keep everyone up to date and to track what has been done and by who." +msgstr "" + +#: version_control/version_control.md:552 +msgid "GitHub also has numerous other handy features such as the ability to raise and assign issues, discuss the project via comments, and review each other's changes." +msgstr "" + +#: version_control/version_control.md:554 +msgid "Making the entire project and its history available online in this was also has two major benefits for research:" +msgstr "" + +#: version_control/version_control.md:556 +# ordered list +msgid "1. Other researchers can re-use the work more easily." +msgstr "" + +#: version_control/version_control.md:557 +msgid "Rather than writing their own code to do what has already been written they can just use the original, which saves time." +msgstr "" + +#: version_control/version_control.md:558 +msgid "This also benefits the project's original authors as other researchers are much more likely to build on the work (and cite it) if a great deal of the work has already been done. " +msgstr "" + +#: version_control/version_control.md:559 +# ordered list +msgid "2. The research will be much more reproducible if the entire history of the project can be tracked. This enables results to be verified more easily, which benefits science." +msgstr "" + +#: version_control/version_control.md:563 +msgid "There are a number of GitHub tutorials available such as [this one](https://guides.GitHub.com/activities/hello-world/), or if you prefer you can follow along here." +msgstr "" + +#: version_control/version_control.md:565 +msgid "First make an account on [GitHub](https://GitHub.com/), and create a repository on it." +msgstr "" + +#: version_control/version_control.md:566 +msgid "To do this click the + sign dropdown menu in the upper right hand of the screen." +msgstr "" + +#: version_control/version_control.md:567 +msgid "Enter a name for the repository (ideally the same name as the project folder on your computer) and click Create Repository." +msgstr "" + +#: version_control/version_control.md:568 +msgid "Now you just need to link the project on your computer to this online repository." +msgstr "" + +#: version_control/version_control.md:569 +msgid "If your project is not already version controlled then make it so by running `git init` and making a commit." +msgstr "" + +#: version_control/version_control.md:570 +msgid "In the terminal on your computer use:" +msgstr "" + +#: version_control/version_control.md:572 +# code block +msgid "```\n" +"git remote add origin https://GitHub.com/your_username/repository_name\n" +"```" +msgstr "" + +#: version_control/version_control.md:576 +msgid "then *push* all the files on your computer to the online version so they match via:" +msgstr "" + +#: version_control/version_control.md:578 +#: version_control/version_control.md:597 +# code block +msgid "```\n" +"git push -u origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:582 +msgid "You can the go on and make more commits on your computer." +msgstr "" + +#: version_control/version_control.md:583 +msgid "When you want to push them to your online version similarly you do:" +msgstr "" + +#: version_control/version_control.md:585 +# code block +msgid "```\n" +"git push origin branch_you_want_to_push_to\n" +"```" +msgstr "" + +#: version_control/version_control.md:589 +msgid "Others can then clone the repository to their computer by using:" +msgstr "" + +#: version_control/version_control.md:591 +# code block +msgid "```\n" +"git clone https://GitHub.com/your_username/repository_name.Git\n" +"```" +msgstr "" + +#: version_control/version_control.md:595 +msgid "They can make and commit changes to the code without impacting the original, and push their changes to *their* online GitHub account using:" +msgstr "" + +#: version_control/version_control.md:601 +msgid "Naturally the exact same procedure applies to you if you want to clone someone else's repository." +msgstr "" + +#: version_control/version_control.md:603 +# header +msgid "#### Pull requests" +msgstr "" + +#: version_control/version_control.md:605 +msgid "So everyone's got a copy of the code and they're merrily working away on it, how do collaborators share their work?" +msgstr "" + +#: version_control/version_control.md:606 +msgid "Pull requests." +msgstr "" + +#: version_control/version_control.md:607 +msgid "A pull request is a request for a person to *pull* someone else's changes into their version on the project." +msgstr "" + +#: version_control/version_control.md:608 +msgid "Say person A has made changes they want to share with person B." +msgstr "" + +#: version_control/version_control.md:609 +msgid "On GitHub Person A needs to go to person B's copy of the project and click the \"New pull request\" button." +msgstr "" + +#: version_control/version_control.md:610 +msgid "From there they can indicate which of their branches they would like person B to pull changes from, and which branch they want the changes pulled to." +msgstr "" + +#: version_control/version_control.md:611 +msgid "If person B accepts then person A's changes will be merged into their repository by GitHub." +msgstr "" + +#: version_control/version_control.md:612 +msgid "They can discuss the request in comments, and make further commits to the request before it is accepted if necessary." +msgstr "" + +#: version_control/version_control.md:614 +msgid "When person B is setting up the pull request GitHub will automatically check whether there would be any merge conflicts if they accept, and highlight them if there are." +msgstr "" + +#: version_control/version_control.md:615 +msgid "These can then be resolved in further commits before the request is accepted, keeping the merge clean and painless." +msgstr "" + +#: version_control/version_control.md:617 +msgid "Once the request is accepted GitHub will merge person A's changes into person B's online copy of the repository." +msgstr "" + +#: version_control/version_control.md:618 +msgid "Person B can the *pull* those changes down to the copy on their computer using:" +msgstr "" + +#: version_control/version_control.md:620 +# code block +msgid "```\n" +"git pull origin master\n" +"```" +msgstr "" + +#: version_control/version_control.md:624 +msgid "It is also possible to make pull requests via the command line." +msgstr "" + +#: version_control/version_control.md:625 +msgid "A guide on how to do so is available [here](https://Git-scm.com/docs/Git-request-pull)." +msgstr "" + +#: version_control/version_control.md:629 +msgid "In your GitHub repository you should **include a license** to allow others to re-use your work legally." +msgstr "" + +#: version_control/version_control.md:630 +msgid "GitHub makes this very easy, simply click the \"Create new file\" button, name it \"License.md\" and a drop down menu will appear offering you a selection to choose from. The legalese can seem intimidating however [this](https://choosealicense.com/) website offers a very simple mechanism to help you pick the best license for your project." +msgstr "" + +#: version_control/version_control.md:632 +msgid "You should also **include a readme file** where you include useful information about what the project is, how to use it and how to contribute to it." +msgstr "" + +#: version_control/version_control.md:633 +msgid "Switching between projects in your work is common, let alone that you might need to poke at your own previous projects from time to time." +msgstr "" + +#: version_control/version_control.md:634 +msgid "This information will also assist you collaborators, and your future employer might want to check your existing GitHub projects." +msgstr "" + +#: version_control/version_control.md:636 +msgid "There are plenty of readme templates available online, pick one you like, but here is a list of the main things a readme should include:" +msgstr "" + +#: version_control/version_control.md:638 +# unordered list +msgid "- The project name and what it is: This will greatly help the random prospective contributor to get an idea of the project." +msgstr "" + +#: version_control/version_control.md:639 +msgid "Include a few key points that describe the main features of the project and what are the main features you are implementing." +msgstr "" + +#: version_control/version_control.md:640 +msgid "This helps to quickly compare other projects with yours and to give an idea that why the project exists in the first place." +msgstr "" + +#: version_control/version_control.md:641 +# unordered list +msgid "- Instructions on how to install the project: The installer might be a collaborator, someone that comes across and is interested in the project, or even you if you get a new machine and need to re-install your project." +msgstr "" + +#: version_control/version_control.md:642 +msgid "Nevertheless, it's a total waste of both of your resources to start figuring out how to just get started with the project." +msgstr "" + +#: version_control/version_control.md:643 +msgid "This should also include any prerequisites that will be needed to run the project." +msgstr "" + +#: version_control/version_control.md:644 +msgid "The best thing you can do is to just write up the installation instructions when you first do them yourself, and you will quickly save hours of work in the future." +msgstr "" + +#: version_control/version_control.md:645 +# unordered list +msgid "- Instructions for how to run the project and any associated tests: If you have been working on your project it may seem obvious how to run it, but this will likely not be the case for someone coming across it for the first time." +msgstr "" + +#: version_control/version_control.md:646 +# unordered list +msgid "- Links to related material." +msgstr "" + +#: version_control/version_control.md:647 +# unordered list +msgid "- List of authors/contributors to the project, possibly with contact information." +msgstr "" + +#: version_control/version_control.md:648 +# unordered list +msgid "- Acknowledgements." +msgstr "" + +#: version_control/version_control.md:650 +msgid "It can be a good idea to **include documents outlining a code of conduct, agreed ways of working, and contributing guidelines**, though depending on the level of detail you want to provide the latter two can also work as sections within the readme." +msgstr "" + +#: version_control/version_control.md:651 +msgid "These documents make explicit expectations for those working on/contributing to the project, making life easier for everyone." +msgstr "" + +#: version_control/version_control.md:652 +msgid "Similarly depending on the scope of your project you may wish to **provide templates for how contributors should make pull requests or raise issues**." +msgstr "" + +#: version_control/version_control.md:654 +msgid "You can also **make use of one of GitHub's major features- issues**." +msgstr "" + +#: version_control/version_control.md:655 +msgid "Anyone can raise an issue with the project and discuss it." +msgstr "" + +#: version_control/version_control.md:656 +msgid "By making issues for any significant changes a record can be kept of the history of the project." +msgstr "" + +#: version_control/version_control.md:657 +msgid "GitHub has a myriad of other features such a milestones and project boards which may also be of use." +msgstr "" + +#: version_control/version_control.md:659 +msgid "In pull requests you should **clearly explain what the changes you've made are and why you made them**." +msgstr "" + +#: version_control/version_control.md:660 +msgid "If your changes address and issue that has been raised reference it directly." +msgstr "" + +#: version_control/version_control.md:661 +msgid "If your request fixes and issue and you include \"will fix #the_issue_number >\" in the pull request, if the pull request is merged it will automatically close the referenced issue, keeping the issue queue nice and clean!" +msgstr "" + +#: version_control/version_control.md:662 +msgid "This also works for using commit messages to close issues too." +msgstr "" + +#: version_control/version_control.md:664 +# header +msgid "## Summary of key Git commands" +msgstr "" + +#: version_control/version_control.md:666 +msgid "| Command | Use |" +msgstr "" + +#: version_control/version_control.md:667 +msgid "| ----------------------------- | ------------------------------------------------------------------------ |" +msgstr "" + +#: version_control/version_control.md:668 +msgid "| git init | Initialises a Git repository in that directory |" +msgstr "" + +#: version_control/version_control.md:669 +msgid "| git add . | Add all changes to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:670 +msgid "| git add file_name | Add changes to the specified file to the staging area to be committed |" +msgstr "" + +#: version_control/version_control.md:671 +msgid "| git commit | Commits staged changes and allows you to write a commit message |" +msgstr "" + +#: version_control/version_control.md:672 +msgid "| git checkout SHA | Check out past commit with the given SHA |" +msgstr "" + +#: version_control/version_control.md:673 +msgid "| git checkout SHA -- file_name | Check out past version of a file from the commit with the given SHA | " +msgstr "" + +#: version_control/version_control.md:674 +msgid "| git checkout -b branch_name | Create and switch to a new branch |" +msgstr "" + +#: version_control/version_control.md:675 +msgid "| git checkout branch_name | Switch to a specified branch |" +msgstr "" + +#: version_control/version_control.md:676 +msgid "| git merge branch_name | Merge the branch you are on into the specified branch |" +msgstr "" + +#: version_control/version_control.md:677 +msgid "| git clone url | Makes a clone of the repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:678 +msgid "| git remote add origin url | Links local repository and repository at the specified url |" +msgstr "" + +#: version_control/version_control.md:679 +msgid "| git push origin branch_name | Push local changes to the specified branch of the online repository |" +msgstr "" + +#: version_control/version_control.md:680 +msgid "| git pull origin branch_name | Pull changes to online repository into local repository |" +msgstr "" + +#: version_control/version_control.md:681 +msgid "| git log | Output a log of past commits with their commit messages |" +msgstr "" + +#: version_control/version_control.md:682 +msgid "| git status | Output status including what branch you're on & what changes are staged |" +msgstr "" + +#: version_control/version_control.md:683 +msgid "| git diff | Output difference between working directory and most recent commit |" +msgstr "" + +#: version_control/version_control.md:684 +msgid "| git diff thing_a thing_b | Output difference between two things, such as commits and branches | " +msgstr "" + +#: version_control/version_control.md:686 +# header +msgid "## Checklists" +msgstr "" + +#: version_control/version_control.md:688 +# header +msgid "### Make use of Git" +msgstr "" + +#: version_control/version_control.md:689 +# unordered list +msgid "- [ ] Make your project version controlled by initialising a Git repository in its directory using `git init`." +msgstr "" + +#: version_control/version_control.md:690 +# unordered list +msgid "- [ ] Add and commit all your files to the repository using `git add .` then `git commit`." +msgstr "" + +#: version_control/version_control.md:691 +# unordered list +msgid "- [ ] Continue to add and commit changes as your project progresses. Stage the changes in specific files to be committed with `git add filename`, and add messages to your commits." +msgstr "" + +#: version_control/version_control.md:692 +# unordered list +msgid " - [ ] Each commit should make one simple change." +msgstr "" + +#: version_control/version_control.md:693 +# unordered list +msgid " - [ ] No generated files committed." +msgstr "" + +#: version_control/version_control.md:694 +# unordered list +msgid " - [ ] Commit messages are meaningful, with a ~50 character summary at the top." +msgstr "" + +#: version_control/version_control.md:695 +# unordered list +msgid " - [ ] Commit messages are in the present tense and imperative." +msgstr "" + +#: version_control/version_control.md:696 +# unordered list +msgid "- [ ] Develop new features on their own branches, which you can create via `git checkout -b branch_name` and switch between via `git checkout branch_name`." +msgstr "" + +#: version_control/version_control.md:697 +# unordered list +msgid " - [ ] Branches have informative names." +msgstr "" + +#: version_control/version_control.md:698 +# unordered list +msgid " - [ ] Master branch is kept clean." +msgstr "" + +#: version_control/version_control.md:699 +# unordered list +msgid " - [ ] Each branch has a single purpose and only changes related to that purpose are made on it." +msgstr "" + +#: version_control/version_control.md:700 +# unordered list +msgid "- [ ] Once features are complete merge their branches into the master branch by switching to the feature branch and running `git merge master`." +msgstr "" + +#: version_control/version_control.md:701 +# unordered list +msgid " - [ ] Merge other's changes into your work frequently." +msgstr "" + +#: version_control/version_control.md:702 +# unordered list +msgid " - [ ] When dealing with merge conflicts make sure you fully understand both versions before trying to resolve them." +msgstr "" + +#: version_control/version_control.md:704 +# header +msgid "### Put your project on GitHub" +msgstr "" + +#: version_control/version_control.md:705 +# unordered list +msgid "- [ ] Create a GitHub account." +msgstr "" + +#: version_control/version_control.md:706 +# unordered list +msgid "- [ ] Create a repository on GitHub with the same name as your project." +msgstr "" + +#: version_control/version_control.md:707 +# unordered list +msgid "- [ ] Attach your local and online repositories via `git remote add origin repository_url`." +msgstr "" + +#: version_control/version_control.md:708 +# unordered list +msgid "- [ ] Put the files in your local version of the project online via `git push -u origin master`." +msgstr "" + +#: version_control/version_control.md:709 +# unordered list +msgid "- [ ] Continue to push changes you make on your computer to the GitHub version via `git push origin branch_name`." +msgstr "" + +#: version_control/version_control.md:710 +# unordered list +msgid "- [ ] Pull any changes made on GitHub to your local version via `git pull origin branch_name`." +msgstr "" + +#: version_control/version_control.md:711 +# unordered list +msgid "- [ ] Include a license." +msgstr "" + +#: version_control/version_control.md:712 +# unordered list +msgid "- [ ] Include a readme." +msgstr "" + +#: version_control/version_control.md:713 +# unordered list +msgid "- [ ] Set expectations for how collaborators are expected to behave via a code of conduct and or ways of working document." +msgstr "" + +#: version_control/version_control.md:714 +# unordered list +msgid "- [ ] Use issues to track and discuss modifications to the project." +msgstr "" + +#: version_control/version_control.md:716 +# header +msgid "### Contribute to someone else's project" +msgstr "" + +#: version_control/version_control.md:717 +# unordered list +msgid "- [ ] Clone their project's repository from GitHub `git clone repository_url`." +msgstr "" + +#: version_control/version_control.md:718 +# unordered list +msgid "- [ ] Make and commit changes." +msgstr "" + +#: version_control/version_control.md:719 +# unordered list +msgid "- [ ] Push your changes to you GitHub version of the project." +msgstr "" + +#: version_control/version_control.md:720 +# unordered list +msgid "- [ ] Make use of issues to discuss possible changes to a project." +msgstr "" + +#: version_control/version_control.md:721 +# unordered list +msgid "- [ ] Make pull requests on GitHub to share your work." +msgstr "" + +#: version_control/version_control.md:722 +# unordered list +msgid " - [ ] Clearly explain the changes you've made and why in your pull request." +msgstr "" + +#: version_control/version_control.md:724 +# header +msgid "## What to learn next" +msgstr "" + +#: version_control/version_control.md:726 +msgid "Look into best practice for writing good quality code (for example, good naming conventions, informative comments, modular code structure)." +msgstr "" + +#: version_control/version_control.md:727 +msgid "Many such skills are either also applicable for using version control well, for example, for writing good commit messages, or make using version control easier by keeping changes neat and localised." +msgstr "" + +#: version_control/version_control.md:729 +# header +msgid "## Further reading" +msgstr "" + +#: version_control/version_control.md:731 +# unordered list +msgid "- A free and very in depth book on Gits myriad of features can be found [here](https://Git-scm.com/book/en/v2)." +msgstr "" + +#: version_control/version_control.md:732 +# unordered list +msgid "- A useful Git cheat sheet can be found [here](https://services.GitHub.com/on-demand/downloads/GitHub-Git-cheat-sheet.pdf)." +msgstr "" + +#: version_control/version_control.md:733 +# unordered list +msgid "- Interactive tutorials for familiarising yourself with GitHub can be found at [https://lab.github.com/](https://lab.github.com/)." +msgstr "" + +#: version_control/version_control.md:735 +# header +msgid "## Definitions/glossary" +msgstr "" + +#: version_control/version_control.md:737 +# unordered list +msgid "- **Add:** Command used to add files to the staging area. Allows the user to specify which files or directories to include in the next commit." +msgstr "" + +#: version_control/version_control.md:738 +# unordered list +msgid "- **Branch:** A parallel version of a repository. Although it is contained within the same repository it allows you to develop it separately and then merge changes back into the 'live' repository or with other branches when appropriate." +msgstr "" + +#: version_control/version_control.md:739 +# unordered list +msgid "- **Checkout:** Git command to switch to a specific file, branch, or commit. Allows you to activate older versions of files or commits or switch between active branches." +msgstr "" + +#: version_control/version_control.md:740 +# unordered list +msgid "- **Clone:** Copy of an existing Git repository, normally from some remote location to your local environment. When you clone a repo you copy its entire history as well as all branches." +msgstr "" + +#: version_control/version_control.md:741 +# unordered list +msgid "- **Commit:** Snapshot of project history. A commit can be made after changes of a single file or a range of files and directories." +msgstr "" + +#: version_control/version_control.md:742 +# unordered list +msgid "- **Commit message:** A message the user can attach to a commit to explain what it contains." +msgstr "" + +#: version_control/version_control.md:743 +# unordered list +msgid "- **Git:** Version control system that GitHub is built around. It is a widely used open source distributed version control system developed by the author of Linux." +msgstr "" + +#: version_control/version_control.md:744 +# unordered list +msgid "- **GitHub:** An online hosting and version control service which centres around the version control software Git. It has a great many features to aid collaboration between users." +msgstr "" + +#: version_control/version_control.md:745 +# unordered list +msgid "- **HEAD:** the latest commit on the branch which is currently checked out" +msgstr "" + +#: version_control/version_control.md:746 +# unordered list +msgid "- **Issues:** Bug tracking system for GitHub. Collaborators can use issues to report bugs, request features, or set milestones for projects. Issues are tracked, reported, and closed by collaborators during the development process. They’re a great way of communicating with your team and reporting progress." +msgstr "" + +#: version_control/version_control.md:747 +# unordered list +msgid "- **Master:** the repository’s main branch. Depending on the work flow it is the one people work on or the one where the integration happens." +msgstr "" + +#: version_control/version_control.md:748 +# unordered list +msgid "- **Merge:** The process of combining branches. Changes made on one or more branches are applied to another." +msgstr "" + +#: version_control/version_control.md:749 +# unordered list +msgid "- **Merge conflict:** Incompatibilities between branches being merged." +msgstr "" + +#: version_control/version_control.md:750 +# unordered list +msgid "- **Pull request:** Proposed changes to a remote repository. Collaborators without write access can send a pull request to the administrator with the changes they've made to the repo. The administrator can then approve and merge or reject the changes to the main repository. For open source projects pull requests can be sent by anyone that has forked a project." +msgstr "" + +#: version_control/version_control.md:751 +# unordered list +msgid "- **Push:** Sending changes to a remote repo. The remote repository is updated with the changes pushed and now mirrors the local repo." +msgstr "" + +#: version_control/version_control.md:752 +# unordered list +msgid "- **Repository:** Refers to a project folder that is being tracked by Git and containing project files. Also called 'repo' for short they can be local as well as hosted on GitHub." +msgstr "" + +#: version_control/version_control.md:753 +# unordered list +msgid "- **SHA:** Unique string of numbers of letters used to identify every commit or node in the repository." +msgstr "" + +#: version_control/version_control.md:754 +# unordered list +msgid "- **Staged:** Changes that will be included in the next commit." +msgstr "" + +#: version_control/version_control.md:756 +# header +msgid "## Bibliography" +msgstr "" + +#: version_control/version_control.md:758 +# unordered list +msgid "- [1.](https://git-scm.com/book/en/v2/Getting-Started-About-Version-Controls) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:759 +# unordered list +msgid "- [2.](https://link.springer.com/article/10.1186/1751-0473-8-7) **Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0)** *Other useful stuff in this paper, could use their into as part of the book's intro*" +msgstr "" + +#: version_control/version_control.md:760 +# unordered list +msgid "- [3.](http://crlionline.net/node/198) **Permission to use given by the author (Peter Reimann) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:761 +# unordered list +msgid "- [4.](https://tonysyu.github.io/source-control-for-scientists-and-soloists.html#.XA6Q3mj7RPY) **Permission given by the author (Tony Yu) 15/12/18**" +msgstr "" + +#: version_control/version_control.md:762 +# unordered list +msgid "- [5.](https://git-scm.com/book/en/v2/Git-Basics-Getting-a-Git-Repository#ch02-git-basics-chapter) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.**" +msgstr "" + +#: version_control/version_control.md:763 +# unordered list +msgid "- [6.](https://githowto.com/undoing_committed_changes) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:764 +# unordered list +msgid "- [7.](https://www.atlassian.com/git/tutorials/saving-changes/git-diff) **Creative Commons Attribution 2.5 Australia License.**" +msgstr "" + +#: version_control/version_control.md:765 +# unordered list +msgid "- [8.](http://sethrobertson.github.io/GitBestPractices/) **Creative Commons Attribution-ShareAlike 3.0 Generic**" +msgstr "" + +#: version_control/version_control.md:766 +# unordered list +msgid "- [9.](https://guide.esciencecenter.nl/best_practices/version_control.html) **Creative Commons Attribution 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:767 +# unordered list +msgid "- [10.](https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project) **Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License**" +msgstr "" + +#: version_control/version_control.md:768 +# unordered list +msgid "- [11.](https://opensource.com/article/18/5/git-branching) **Creative Commons license**" +msgstr "" + +#: version_control/version_control.md:769 +# unordered list +msgid "- [12.](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches) **GNU GENERAL PUBLIC LICENSE Version 3**" +msgstr "" + +#: version_control/version_control.md:770 +# unordered list +msgid "- [13.](http://genomewiki.ucsc.edu/index.php/Resolving_merge_conflicts_in_Git) **[\"You are granted a limited license to copy anything from this site\"](http://genomewiki.ucsc.edu/index.php/Genomewiki:General_disclaimer)**" +msgstr "" + +#: version_control/version_control.md:771 +# unordered list +msgid "- [14.](https://githowto.com/resolving_conflicts) **creative commons Attribution-NonCommercial-ShareAlike 4.0 International**" +msgstr "" + +#: version_control/version_control.md:772 +# unordered list +msgid "- [15.](https://opensource.com/article/18/1/step-step-guide-git) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:773 +# unordered list +msgid "- [16.](https://kbroman.org/github_tutorial/pages/init.html) **Attribution 3.0 Unported (CC BY 3.0)**" +msgstr "" + +#: version_control/version_control.md:774 +# unordered list +msgid "- [17.](https://opensource.com/article/18/2/how-clone-modify-add-delete-git-files) **Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**" +msgstr "" + +#: version_control/version_control.md:775 +# unordered list +msgid "- [18.](https://thejunkland.com/blog/how-to-write-good-readme.html) **Creative Commons Attribution-NonCommercial 2.5 License**" +msgstr "" + +#: version_control/version_control.md:776 +# unordered list +msgid "- [19.](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) **MIT**" +msgstr "" + +#: version_control/version_control.md:777 +# unordered list +msgid "- [20.](https://commons.wikimedia.org/wiki/Taj_Mahal#/media/File:Taj_Mahal_in_March_2004.jpg) **GNU Free Documentation License**" +msgstr "" + +#: version_control/version_control.md:778 +# unordered list +msgid "- [21.](https://juristr.com/blog/2013/04/git-explained/) **Creative Commons Attribution-ShareAlike 4.0 International License**" +msgstr "" + +#: version_control/version_control.md:779 +# unordered list +msgid "- [22.](http://simpleprimate.com/github-for-web-designers/glossary.html) **Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)**" +msgstr "" + diff --git a/book/website/Makefile b/book/website/Makefile index cc37ba917d2..bdbbc5c3e4d 100755 --- a/book/website/Makefile +++ b/book/website/Makefile @@ -27,6 +27,7 @@ serve: bundle exec guard build: + bash scripts/multilingual_make.sh jupyter-book build ./ --overwrite site: build diff --git a/book/website/_config.yml b/book/website/_config.yml index d1d16ce3db4..dcce95e5eaa 100755 --- a/book/website/_config.yml +++ b/book/website/_config.yml @@ -149,6 +149,12 @@ exclude: - vendor/gems/ - vendor/ruby/ +keep_files: +- zh_CN +- zh-cn +- es +- tr + plugins: - jekyll-redirect-from - jekyll-scholar diff --git a/book/website/requirements.txt b/book/website/requirements.txt index 430c390002c..27cacc5900f 100755 --- a/book/website/requirements.txt +++ b/book/website/requirements.txt @@ -5,4 +5,5 @@ numpy datascience folium matplotlib +nbconvert==5.5 jupyter-book==0.6.4 diff --git a/book/website/runtime.txt b/book/website/runtime.txt index 548d71365f0..cc1923a40b1 100755 --- a/book/website/runtime.txt +++ b/book/website/runtime.txt @@ -1 +1 @@ -3.7 \ No newline at end of file +3.8 diff --git a/book/website/scripts/multilingual_make.sh b/book/website/scripts/multilingual_make.sh new file mode 100644 index 00000000000..ebd4800fcb8 --- /dev/null +++ b/book/website/scripts/multilingual_make.sh @@ -0,0 +1,30 @@ +cd ../.. +git clone https://github.com/tonyyzy/po4jupyterbook +cd book/content +# Compile Markdown files from POT files +python3 ../../po4jupyterbook/tools/poc.py +cd ../website +# Copy the config file and change the location of the content to locale where +# the translated Markdown files will be +sed 's+content_folder_name: ../content+content_folder_name: ../content/locale/+g' _config.yml > _config-locale.yml +# Make backup of the original table of content +cp _data/toc.yml _data/toc.yml.bak +cat ../content/po/LINGUAS | while read lang; +do + echo ${lang} + # Make language specific table of content + sed "s/url: /url: \/${lang}\//g" ../content/po/toc.yml > _data/toc.yml + # Use the locale config to build each language version of the book + jupyter-book build ./ --overwrite --config _config-locale.yml + # Change the path to figures directory one level higher + # This will use the figures from the English version + # Should a translated figure exist, it will reside in a folder different + # from the sed match here + find _build/${lang}/ -name *.html -exec sed -ie "s+\.\./figures+../../figures+g" {} \; + bundle exec jekyll build + # Remove the translated Markdown from the _build directory otherwise jekyll + # will build those files again + rm -r _build/${lang} +done +# Restore the table of content to the oiginal version +cp _data/toc.yml.bak _data/toc.yml \ No newline at end of file diff --git a/screenshots/copyTranslation.png b/screenshots/copyTranslation.png new file mode 100644 index 00000000000..7addcf29af3 Binary files /dev/null and b/screenshots/copyTranslation.png differ diff --git a/screenshots/dashboard.png b/screenshots/dashboard.png new file mode 100644 index 00000000000..2839e9da160 Binary files /dev/null and b/screenshots/dashboard.png differ diff --git a/screenshots/joinRequestTranslate.png b/screenshots/joinRequestTranslate.png new file mode 100644 index 00000000000..2587d4f3198 Binary files /dev/null and b/screenshots/joinRequestTranslate.png differ diff --git a/screenshots/joinTranslate.png b/screenshots/joinTranslate.png new file mode 100644 index 00000000000..75d70772b51 Binary files /dev/null and b/screenshots/joinTranslate.png differ diff --git a/screenshots/saveTranslation.png b/screenshots/saveTranslation.png new file mode 100644 index 00000000000..a02051d9004 Binary files /dev/null and b/screenshots/saveTranslation.png differ diff --git a/translation_guide.md b/translation_guide.md new file mode 100644 index 00000000000..9521350c140 --- /dev/null +++ b/translation_guide.md @@ -0,0 +1,93 @@ +# Translation Guide + +This guide will help you contribute to an existing language translation of The Turing Way, start the process of translating a new language, as well as a few hints when translating and some implementation details. + +## How to join an existing translation team? + +Go to [Transifex](https://www.transifex.com/theturingway/theturingway/) and click "Help Translate TheTuringWay" (button in blue). If you don't already have an account, you'll be asked to sign up for a free account. Once signed in, you can then "Join a team" to contribute to an existing translation or start a new language translation by "Request language" and follow the instructions in the section below. + +

+

+ +## How to start a new translation? + +If there's not a translation for a language you want to add, you can follow the steps below (note that these steps only need to be carried out once per language). + +- To start a new language, within the `the-turing-way` repository, + - In `book/content/po` directory contains POT and PO files. POT files are generated from the Markdown files and contains the original strings of the book; PO files contain the original string and their translations. + - add the language's ISO code to: + - the `LINGUAS` file in `book/content/po` - and make sure to keep a newline character at the end of the file + - and to the `keep_files` list in `book/website/_config.yml` + - From within `book/content`, we then need to copy all the POT files to make corresponding PO files with the following bash command, + + `for FILE in *.pot; do echo $FILE; cp $FILE ${FILE%%.*}..po; done` + +Once your request of a new language has been accepted by the maintainer, you'll then be able to start contributing your translations! + + + + + +## Translating on Transifex + +After signing in and joining "TheTuringWay" organisation, you will then be able to start contributing translations by clicking the "Translate" button in the Transifex dashboard (shown below). Remember that in order to start contributing for a particular language, you'll need to "Join the team" first. + +

+ +From there, you'll be offered a list of sections of the book to select and can then add your translation for individual lines of the book and save the translation. + +

+ +As shown above the lines to translate also include the Markdown syntax (`#`, for example) and its important to keep these when translating to keep the original structure of the book. You can automatically copy this to the translated version, which is useful when dealing Markdown syntax such as tables. + +

+ +## What happens when the markdown content of the book changes? + +When the Markdown files are updated, you will need to update the POT files for the new strings to show up in Transifex. + + - Clone `po4jupyterbook` to the root directory of the project, within `the-turing-way` repository, + + `git clone https://github.com/tonyyzy/po4jupyterbook` +- Then, from within `the-turing-way/book/content` run, + + `../../po4jupyterbook/create.sh` + +This will update the POT files to track the modified Markdown files. Since there are timestamps in the POT files, git will always show there is something to commit even all the marterial is the same. To make this CI-able, we can remove the timestamp from the `po4jupyterbook` code. We shall only update the POT files manually when we know for sure there are changes for now. + +## Implementation details + +The philosophy behind the implementation is to make translation work without impacting the existing build process. Jupyterbook builds by copying the Markdown files to the `_build` directory under `book/website` with some parts added. Jekyll builds by compiling the Markdown files to HTML files in the `_site` directory. + +The shell script that handles building of the translations is in [`book/website/scripts/multilingual_make.sh`](book/website/scripts/multilingual_make.sh) + +A rundown of steps taken by `multilingual_make.sh`: +- clone `po4jupyterbook` to the root directory of the repository +- compile the translated markdown files to `book/content/locale` +- copy and make a config file for Jupyterbook to build the translations +- for each language in [`book/content/po/LINGUAS`](book/content/po/LINGUAS) + - make specific table of content file for this language by adding the language code to the start of the URL + - `jupyter-book build` copys Markdown files to the `_build` directory and adds some boilderplate parts + - use `find` and `sed` to substitute all the `../figures` to `../../figures` so the figures can be directed corretly + - Jekyll build + - remove the Markdowns from the `_build` directory so they don't get built by Jekyll again in another language build +- Restore the table of content file to the original version for the English version build + +### Transient files during the build process + +The table of content for (`toc.yml`) contains the book structure and controls the urls of the book. We only need to maintain one version of the file as the table of content for each language is generated during the build process by adding the language code to the urls. + +The configuration file for Jupyterbook (`_config.yml`) points to where to find the book content Markdown files. + +### Translation of pictures + +We hope that pictures and illustrations can be translated as well. Those pictures can be stored in the same place as the original ones with language code added. + +## Commonly asked questions + +- When will my translations appear in the book? + + Contributed translations will appear in the online book once the `translation` branch will be merged into the `master` branch of `the-turing-way` repository. + + +TODO: this guide is a work in progress - need to add points about general contributing guidelines such as priority of sections to translate for people willing to translate.